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

Re: File modification detection?

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-04-17 22:39:53 CEST

Andy Whitcroft wrote:

> It appears that the client file modification detection is incorrectly
> checking modification time and assuming that if that is unchanged the
> file is unchanged even in the face of the size/inode number changing.

That is exactly what's happening. SVN uses the same algorithm as CVS to
detect if a file has changed:

   if (file's timestamp == one recorded in .svn/entries)
      return NOT_CHANGED
   else if (size of file != size of .svn/text-base/file)
      return CHANGED
      compare file and .svn/text-base/file byte-by-byte.

So what you're doing is 'mv'ing a different file with identical
timestamp on top of the file, and the algorithm is falling down.

Developers: is this a legitimate hole in our algorithm? Should we
change it to cover this edge-case?

I'm worried that the only way to prevent this is to always-stat the
text-base (which will slow down things even further, since we're doing
two file stats instead of one), or to record the text-base's size in our
entries file.

Still, though, I could imagine somebody 'moving' a file with identical
timestamp *and* identical size on top of the working file, and still
fooling the algorithm. So is this road even worth pursuing? Is there
some nice philosophical quip that allows us to brush off this whole
scenario? Something like, "don't fool with timestamps, kid".

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 17 22:37:28 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.