rounding timestamps (or not)

[Jeremy Allison]

On Tue, Sep 14, 2010 at 01:07:50AM +0200, Björn Jacke wrote:
> looks like the explaination of the problem wasn't very clear :-)
> 
> Some examples to illustrate what I mean:
> 
> case 1) if we have a filesystem with 1s timestamp granularity and a client for
> example sets the time of a file to 10:10:10.4 then the filestamp will be set to
> 10:10:10 (CORRECT IMHO) (if client later on requests the filetime it's not
> newer than the one he set it to)
> 
> case 2) if we have a filesystem with 1s timestamp granularity and a client for
> example sets the time of a file to 10:10:10.5 then the filestamp will be set to
> 10:10:11 because we round up (a PROBLEM!?) (if client later on requests
> the filetime it *IS* newer than the one he set it to)
> 
> case 3) if we have a filesystem with µs timestamp granularity (or don't have
> the utimensat() function) and a client for example sets the time of a file to
> 10:10:10.0000004 then the filestamp will be set to 10:10:10.000000 (CORRECT
> IMHO) ...
> 
> case 4) if we have a filesystem with µs timestamp granularity (or don't have
> the utimensat() function) and a client for example sets the time of a file to
> 10:10:10.0000005 then the filestamp will ALSO be set to 10:10:10.000000 because
> rounding is not performed (which is CORRECT IMHO) ...
> 
> 
> So in the end this means round_timespec() just rounds in case of 1s granularity
> but we really want to truncate and not to round anyway in smb_set_file_time(),
> don't we?

Now I see what you mean, but this isn't the timestamp bug
that caused problems.

The timestamp bug was :

a) Client sets timestamp on open file.
b) Client reads timestamp it just set on open file.
c) Client closes file
d) Client reads timestamp it just set on pathname.

If the timestamps in (b) and (d) are different, there's
a problem. Clients don't care so much about the time
changes for rounding or truncation, they care that
the rounding or truncation is done identically in all
cases.

Jeremy.