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.
-J
--
AOLserver - http://www.aolserver.com/
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.
