Your right, the code snippet below could trip over a race condition as
you've described. But, that's not reason enough to change the
fastpath, it's reason to better document the behavior so folks don't
write code that uses ns_returnfile for temporary, dynamic content.
Although fastpath takes care to be correct in most cases (e.g.,
stat'ing the file on each request and serializing read on cache miss),
the "fast" in fastpath is because it's primarily designed to return
simple static content with minimal overhead.
BTW: I believe the ns_returnfile command didn't use the fastpath
originally -- I think it just opened and sent the content. It was
changed because folks asked for it to go faster I think -- can't recall.
Anyway, for your app, it might be easiest to not change your code but
instead write a new ns_returnfile to override the builtin -- maybe
just with open and ns_returnfp.
-Jim
On Aug 19, 2008, at 4:00 PM, John Caruso wrote:
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.
--
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.
