avoiding stat() races

[Cole, Timothy D.]

> -----Original Message-----
> From:	okuyamak at dd.iij4u.or.jp [SMTP:okuyamak at dd.iij4u.or.jp]
> Sent:	Saturday, November 11, 2000 1:53
> To:	samba-technical at samba.org
> Subject:	Re: avoiding stat() races
> 
> Dear Timothy
> 
> I'd like to recommend adding 
> 
>     int	 scaceh_fstat( scache *cache, const int fd, SMB_STAT_STRUCT
> *st_buf );
> 
> to the list. Even on application side, we don't wish to search for
> path matching if we don't need to, and still, if we could ask fstat
> information through scache, then scache have chance of updating the
> information.
> 
	Good catch.

> # This means most of the file manipulations, including sendfile()
> # syscall of linux, is something of interest in adding.
> 
> ... Or maybe we should create our own FILE structure, and use it
> instead of file descriptor itself. our FILE structure knows where
> and which scache we should look at.
> 
	That might be preferable.  Foisting the task of maintaining
association between fds and scache * on the API's client is not ideal.

	More objecty, after a fashion, too.

> CTD> 	This is reasonable.
> CTD> 	I still think keeping a separate 'reference counter' regardless of
> CTD> the availible time precision would be preferable.  It's a nice hedge
> against
> CTD> access times passing timestamp resolution (or more important,
> accuracy),
> CTD> which _will_ keep happening.
> 
> ... Maybe we are talking about slightly different "REFERENCE COUNTER".
> 
> You are talking about 'reference counter per file', individual one, right?
> 
	Yes.

> I'm talking about 'reference counter per system'. Single global
> reference counter for one entire Operating system. Any action against
> filesystem will increase reference counter, until 'time' changes.
> 
	What about shared filesystems?

	Wait, no, that's easy.  Use the host kernel's counter.

> And once this was kept, we can merge timestamp and reference counter
> into one field, for any comparison works correctly regardless of
> timestamp accuracy and reference counter, without deep thinking.
> 
	Good point.  I still think the reference counter should be present,
regardless of timestamp resolution, though.