[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: Ben Reser <ben_at_reser.org>
Date: 2004-07-14 18:44:46 CEST

On Tue, Jul 13, 2004 at 11:49:50AM +0200, Klaus Rennecke wrote:
> 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 /
> 2)).
> 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.

Problem is with the current code there isn't really a good place to put
this either. I don't think the client code should be writing files in a
wc (even some dummy file in the admin area) directly. By the time we're
waiting we've already closed the adm_access baton if we had one...

> 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.

If you're using subversion on a USB stick you're probably already out of
luck, w.r.t the lifespan of your USB stick.

Ben Reser <ben@reser.org>
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 14 18:45:06 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.