Tom Jackson wrote:
No, because each file has a different inode. The "bug" requires that you
create and destroy one file and create another one within one second (so
they have the same timestamp) also required that the same inode is used
and that the file is the same exact size.
But beyond that, hopefully your git checkout will maintain the original
timestamp with the file.

The "bug" conditions are actually slightly looser than this, because fastpath checks mtime and not ctime. So a malicious user (or your version control system, if it makes the local files have the same timestamps as those in the repo) could overwrite a file at any point in the future, utime() it back to the same time and fastpath would still consider it the same. So would any number of unix utilities, like rsync, tar, zip, etc.

Going back to my previous solutions, the only one on the server side that I still think is reasonable (names break hardlinks, cache flushing on unlink wasn't good in the first place, -nocache - why bother?) is to add a configuration option to exclude particular paths from fastpath. Actually not even a configuration option; that would involve a bit too much overhead for a marginal case; maybe a patch to fix this problem for users for whom it is a problem.

Using an unlinked file as a temporary is the right thing to do most of the time, but I imagine ti could be difficult to do when you need to pass the filename around to uncooperative external programs.


AOLserver -

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> 
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Reply via email to