On Monday 05:53 PM 8/18/2008, Jeff Rogers wrote:
russell muetzelfeldt wrote:
fastpath is making assumptions about what means something is the "same
file", and those assumptions are not consistent with unix filesystem
semantics - how is this not a bug?
It's not a bug because no one ever said that it *was* strictly following
unix filesystem semantics, which isn't even a single thing (ufs is
slightly different than nfs, is slightly different than ext2 -noatime, is
slightly different than afs, etc.) It is following a particular
definition: if the file still exists and has the same
dev/inode/mtime/size as it did when you last checked, then it is the same
file. This of it as a if-modified-since or if-none-match conditional
GET.
Actually that's not analogous, for the same reason that the analogies to
caching of attributes in NFS, rsync or tar not noticing content changes if
attributes stay the same, etc, don't apply: because this bug can happen
*even with two files that have completely different names or
paths*. Again, in this example...:
set file [open "/var/tmp/myfile" "w"]
puts $file "ABC123"
close $file
ns_returnfile 200 text/plain "/var/tmp/myfile"
ns_unlink -nocomplain "/var/tmp/myfile"
set file [open "/var/tmp/myotherfile" "w"]
puts $file "XYZ987"
close $file
ns_returnfile 200 text/plain "/var/tmp/myotherfile"
ns_unlink -nocomplain "/var/tmp/myotherfile"
...AOLserver will almost always return the contents of /var/tmp/myfile
rather than /var/tmp/myotherfile in response to the second ns_returnfile.
I think the analogies to other systems aren't really germane
anyway--AOLserver's behavior has to be judged on its own merits. But
adopting that standard, I can't think of any other program that would
confuse /var/tmp/myfile with /var/tmp/myotherfile.
- John
--
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.
