On 11/03/2011 15:18, McKown, John wrote:
On a strict reading of the above, you can't rely on a /tmp file
existing "between invocations of the program", in other words when
a file isn't actively held open by a process. This would break many
many shell scripts I've read and written over the years :)
I don't see this. When you run a shell script, there is a shell
process running the entire time with your UID. Or did I say it wrong?
I didn't mean the file existed but was closed. I mean a file existed
with a given UID and no process existed in the system anywhere which
was using that UID. Although if you run setuid programs from a script
... I hadn't thought of that. This is why I'm asking. To avoid a
stupid mistake due to my ignorance.
Sorry, I'm talking about the Linux FHS doc, not your deletion scheme.
Before doing that, however, I'd question why the /tmp directory is
so space-constrained. If software isn't cleaning up its own stuff,
fix it!
Not always within my power. If user refuses due to lack of time, I
can't do anything other than complain and get told to shut up. We are
always short of space. Space costs money. We have no money.
It sounds more like a cultural problem than a technical one at this
point. You're bean-counting on un-quota'd disk space, but have no
leverage to get problem apps addressed?
I see on the mvs-oe thread you've already discussed per-user /tmp areas,
which was going to be my next point :)
Cheers,
Phil
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
