steveb at creek-and-cowley.com
Sat Oct 26 17:07:02 PDT 2002
On Sun, 2002-10-27 at 01:14, Matthias Benkmann wrote:
> "/var/tmp" is more typing and in fact it's not unreasonable to symlink
> /var/tmp and /tmp if you have only one partition. I do this just like I
> symlink /usr/bin and /bin.
I disagree there. Since /tmp and /var/tmp are both world-writable it is
important to have them on separate partitions or filesystems. Of
course, you could still make them the same separate partition.
> One of the main arguments
> in the discussion whether cleanfs should by default wipe /tmp was that
> this could hurt someone badly who doesn't read the scripts (most don't)
> and doesn't expect this (because not all distros do this).
Hand-holding again? I must have been busy and missed this when the
earlier debate came up, so let me voice my opinion now; there are
clearly different sorts of temporary files and there should be both a
place for files which get wiped upon boot (like those locks) and another
place for files which shouldn't get wiped.
Personally, I think the problems generated by permanent /tmp storage are
even more confusing than those that come up without it.
> The X lock file issue is the only issue people in favor of the wipe have
> come up with and the message output by X makes it crystal clear what the
> problem is so that it's easy to see and fix.
GNOME (and other CORBA systems, presumably) also dump files in /tmp.
Not normally a problem but if one of them gets corrupted somehow, it can
make headaches. I've had to deal with this before. ESD also puts a
troublesome lock file there.
Quite a lot of other programs like to dump files in /tmp but don't clean
them up again ("make check" does that in many cases, for example). Even
if programs DO clean up properly, there is always the possibility of a
You aren't seriously recommending that you can just leave /tmp without a
cleanfiles of some sort, are you?
Creek & Cowley Consulting
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev