Hi Folks,
I agree with Eric, even though I wrote the original code and was one
of the first to suggest is wasn't a bug. This thread has surprised me
in a few ways:
-- The bug was indeed subtle and curious
-- The debate on dynamic vs. static and underlying assumptions and
performance was well reasoned
-- The name of the command does indicate something it is not in a way
that matters
-- Folks generally underestimated the impact of this bug except for
those affected
-- The direct personal attacks were a bit embarrassing to watch
Overall, seems like:
-- Patching underlying fastpath to be filename-based keys makes sense
if it's confirmed to solve the problem
-- What ns_returnfile does is good for some things if you know what
it's doing
-- Sending dynamic content with the current ns_returnfile isn't a good
idea
For Eric and John, I'd recommend a Tcl-based ns_retunfile wrapper
using open/ns_returnfp/close as a quick first step.
BTW: The underlying cause -- the rapid re-use of inodes -- is indeed
a behavior of at least Linux but not Mac OS/X. Compare:
Linux:
[EMAIL PROTECTED]:~$ rm -f foo ; touch foo ; stat -c "%d.%i" foo ; rm foo ;
touch foo ; stat -c "%d.%i" foo
2049.712963
2049.712963
Mac OS/X:
[JimBook:~] jimbo% rm -f foo ; touch foo ; stat -f "%d.%i" foo ; rm
foo ; touch foo ; stat -f "%d.%i" foo
234881026.4090565
234881026.4090566
I find this very interesting.... But, maybe I'm odd, I know most of
you have probably long since begun to ignore this thread and it should
probably die now...
Cheers,
-Jim
On Aug 20, 2008, at 3:23 PM, Eric Larkin wrote:
On 8/20/08 11:29 AM, "John Caruso" <[EMAIL PROTECTED]> wrote:
Whether or not that's so, the fact is that everyone on this list
appeared
to share the same utterly natural assumption that "ns_returnfile X"
really
will return file X
All, I've been on vacation or I would have chimed in earlier, but as
John's
client and CTO of the company who found the problem (and is now
faced with a
fairly extensive and difficult impact assessment to determine
whether the
confidentiality and integrity of our customers' data has been
compromised),
I find the suggestion that this is not a bug to be utterly baffling.
Perhaps if the procedure in question was called
"ns_returnfromcache", I
could see the arguments against the behavior being considered a bug,
but the
name of the procedure is "ns_returnfile", and it takes an argument
which is
a filename. Our objective in using the procedure was not to return a
dynamic file through the cache, it was to return a dynamically
generated
file (which was produced by an exec of an OS-level command) from the
filesystem...and the documentation for the procedure certainly did not
suggest that its functionality did not support this usage.
Obviously we'll work around the problem in the future, but it is
disheartening to find a fairly subtle bug, report it with a
reproducible
test case, and be challenged so aggressively on the whether it was a
poor
decision to use "ns_returnfile" to...um...return a file.
Eric
__________________________
Eric Larkin
Chief Technology Officer
Arena Solutions
[EMAIL PROTECTED]
4100 E. Third Ave.| Suite 300 | Foster City | CA 94404
tel: 650.513.3502 | fax: 650.513.3511
--
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.
