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

Re: svn completely looses file modifications due to FAT 2s time resolution (data loss!!?)

From: Klaus Rennecke <kre_at_tigris.org>
Date: 2004-07-13 11:49:50 CEST

Ben Reser wrote:
> On Mon, Jul 12, 2004 at 11:30:51PM +0100, Jon Foster wrote:
>>But this (more realistic?) example fails:
>>12:00:01.50: svn up foo ->timestamp of foo is 12:00:02
>>12:00:01.75: echo change > foo ->timestamp of foo is still 12:00:02
>>... user goes away and does something else ...
>>12:30:00.00: svn ci foo ->outside 5 seconds, does not notice change
> True. b) would fail in this case.

The simplest way to solve this that I can think of is to wait for one
unit of FS resolution on WC. A very localized version that does not need
any information about the preceding operations would be to:

Touch a dummy, wait a small amount of time (maybe configurable), and
keep touching it until its modification time changes. Maybe increment
delay between touches a bit to scale up, like delay' = (delay + (delay /

I am aware that this will probably wait somewhere between 2s to 5s for
FAT filesystems. But it should be on the safe side. And for filesystems
with higher resolution it should be hardly noticeable if the wait 25ms
instead of 10ms.

To reduce FS operations because USB sticks tend to wear out, a floating
average of the amount of time needed to wait could be recorded in the
WC. Two thirds of that value should closely approximate the FS timestamp
resolution. That could be used to choose the initial delay.

Combine the two approaches above and use the file recording the average
as the dummy. Not a dummy anymore then. Compute the average that would
result if modification time rolls now and write it to file to touch it.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 13 11:50:12 2004

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.