[PROPOSAL] Resolution to issue #1960 (2s FAT timestamp resolution)

Currently we're sleeping for timestamps on all filesystems by the same
amount of time (1s). On some FSs, that's a big problem: see issue
#1960 where modifications get lost due to the fact that the FAT
filesystem timestamp resolution is 2s. So, we should be waiting /
sleeping longer on FAT than we actually do.

Searching around, I found a solution to this problem:

I found that all FSs 'truncate' the timestamp when they go from a high
to a lower resolution. This means that if you have a file on ext2
(which has a 1s resolution) and set the timestamp to 22:52:41.5, it
will show you 22:52:41.0. When doing the same thing on VFAT, it'll
show 22:52:40.0.

Now, if we set the timestamp of the 'format' file at creation time to
something with an odd number of seconds and a number of miliseconds,
then all we need is to retrieve the timestamp from the format file to
know what the properties the FS has on which the format file was
created.

Ofcourse, there are a number of problems here:

1) A working copy could get moved to an FS with a higher resolution later.
2) The linux kernel caches inodes and makes VFAT look like ext2/1s
resolution while the inode is still in the cache.
3) The cifs on caches inodes for exactly 1 second and shows a
sub-second resolution until it refreshes the inode.

(1) could be addressed by (re)setting the timestamp when running
cleanup on the working copy

(2) is no worse than we currently do.

(3) is probably not as bad as it looks, because most checkouts take
more than a second and we'd normally only set the timestamp on initial
creation (ie at the start of a checkout)

Comments?

(No, this time, I'm not going to commit any changes before we complete
discussion!)

bye,

Erik.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 14 22:15:11 2007