While I'd agree this is a bug in fastpath, the real problem is that
fastpath is being used at all in this case. The intent of fastpath is
to avoid reading a seldom-changed file from disk. It happens to be used
in ns_returnfile since that is the normal use case. On unix the
fastpath cache is keyed off the dev/inode probably to keep the hash key
shorter. Windows doesn't have device and inode numbers so it uses the
filename as the hashkey, so it wouldn't run into this problem.
From the server side, this could be fixed by:
- adding in the filename to the hash key or checking that it is the same
- making ns_unlink flush the entry from the fastpath cache
- restricting what fastpath will cache - e.g., don't cache anything in
/var/tmp or /tmp or a configuration-specified directory.
- adding a "-nocache" flag to ns_returnfile
All of these have pros and cons.
I don't think your suggestion of waiting for cache entries to age a
second or two would work well, it just moves the race condition around
and adds a whole lot of disk activity when a busy server is warming up -
static files might be read a few dozen times instead of once.
Fixing it from the application side is much easier. Just use
ns_returnfp instead of ns_returnfile, on the open handle if you
generated the file from tcl code and it's convenient to get the handle,
otherwise by opening the file right there:
<<...generate file $myfile in some way...>>
set fp [open $myfile]
ns_returnfp 200 text/plain $fp
close $fp
ns_unlink $myfile
You'd probably lose some efficiency by not mmap-ing the file, but that's
likely to be noise compared to generating the file in the first place.
-J
John Caruso wrote:
On Monday 01:33 PM 8/18/2008, Tom Jackson wrote:
It's not be a data corruption issue
because you are choosing to overwrite the old data with new data using
the exact same file name. If the data is important, don't overwrite it,
thus no corruption.
No, you've misunderstood the scenario. The file name needn't be the
same to trigger this issue, and the "corruption" doesn't come from
serving data out of a file that's changing, but rather because fastpath
caching mistakenly identifies a new file as being identical to a
previously-cached file (for the reasons I outlined) and erroneously
serves the previously-cached data to the user.
This is a design limitation and arguably a bug in the fastpath caching
implementation, which is potentially quite serious since it silently
serves the wrong data to the user. If you want a more straightforward
(albeit contrived) demonstration of the problem, here you go:
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"
Assuming that /var/tmp/myfile and /var/tmp/myotherfile are created
within the same second, the fastpath caching algorithm will misidentify
them as the same file, and ns_returnfile will therefore erroneously
return the (previously cached) contents of /var/tmp/myfile when it
should be returning the (uncached) contents of /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.
