Re: return to the begin of InputStream
On 12/9/2009 10:49 AM, Tom Anderson wrote:
On Sat, 5 Dec 2009, Eric Sosman wrote:
(Marginally topical) [...]
Also, it's a *very* bad idea to purge /tmp blindly, even if you're
careful only to purge files that haven't been modified in a while. I
recall working with a server application that put files in /tmp and
mmap'ed them to share memory between its multiple processes. Since
simple paging I/O to and from a file opened a week ago doesn't change
the files' modification date, along came the customer's /tmp-purging
cron job and BLOOEY went the server ...
Hang on, the files were open, right? So how could they be deleted? Or is
the point that the directory entries were deleted, so when new processes
were spawned, they couldn't open the file? And since when did writing to
a file via an mmap not change its modification time, anyway?
(The topicality margin gets even thinner)
You're right: An open file can't be deleted. However, its
directory entry is removed. Then, when the application spawns a
new process and that new process tries to share memory with the
others by opening and mmap'ing the now-unfindable file, BLOOEY.
(When the customer first reported trouble, I immediately asked
whether there was a cron job or some such that periodically purged
old files from /tmp. Customer asserted -- vehemently and a bit
angrily -- that OF COURSE there wasn't. So we cobbled together
some DTrace to monitor file deletions in /tmp, and caught the
non-existent cron job red-handed ...)
As for file modification times, I confess an incomplete grasp
of exactly which operations do and do not update them. However,
just poking a new value into a page that's mmap'ed from a file is
not enough to update the time stamp. Can you imagine the overhead
if every memory write trapped to the kernel to update the time?
Either way, i'd suggest the bad idea here was putting critical
long-lived files in /tmp. Yes, they're temporary, but not that temporary!
It wasn't my choice. It wasn't even my company's choice.
The third party who wrote the application chose to do things that
way, and even went so far as to include "do_not_delete" as part
of the files' names.
--
Eric Sosman
esosman@ieee-dot-org.invalid