[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion & FAT failures

From: Branko Čibej <brane_at_xbc.nu>
Date: 2005-06-26 07:34:10 CEST

Erik Huelsmann wrote:

>Several weeks ago I asked CarlFK on IRC (#svn) to set up Win32 breakage
>tests on several other Windows flavors than the one sussman's system is
>running (W2k to be exact).
>
>He set up a machine testing on NTFS, which has been running its tests just
>fine, after initial startup problems. The other system (V400) has been
>running tests on FAT. This system has been failing the testsuite from the
>beginning and we haven't been able to fix it since. After a lot of fiddling
>with the system, I decided to verify testing on FAT with sussman's system.
>
>After switching sussman's testsystem to FAT, it started failing lots of
>tests. From the logs, I conclude that status incorrectly reports files as
>unchanged. Checking manually with TSVN, I see the same. 'touch'-ing the file
>turns it into a 'changed' status.
>
>What we have here is the problem that FAT has a 2 second timestamp
>resolution, whereas we only 'sleep-for-timestamps' for 1 second.
>
>Conclusion: We're currently broken for use on FAT.
>
>Question: What to do about it?
>
>Several possible answers:
>- Don't support FAT
>
>
Yuck.

>- Sleep an extra second for timestamps on Windows
>
>
YUCK!!!

>- Set timestamps to the last second which has already passed instead of the
>current one
>- (more?)
>
>
This is issue 1960. When we discussed it, I think the proposed solution
was to create a temporary file, look at its timestamp, and wait only
until that time passes (or keep touching the file until its timestamp
changes). In this way the filesystem would implicitly tell us what its
timestamp resolution is. For example, on NTFS we might end up not
waiting at all, since it has microsecond timestamp resolution.

You get to create and delete another file, but that's once per client
operation.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jun 26 07:35:04 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.