Re: File modification detection?

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