Matthias Benkmann matthias at winterdrache.de
Sun Oct 27 07:20:08 PST 2002

On 27 Oct 2002 08:07:02 +0800 "S. Bougerolle"
<steveb at creek-and-cowley.com> wrote:

> > 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?

There's a difference between avoiding hand-holding and deliberately
risking someone's data. It doesn't matter if this someone should have read
the bootscripts or not. There are some things that are simply
inacceptable. Risking the data of even 1 in a 1000 LFS users just to
accomodate some people's notion of correctness is one of these things. 

> Personally, I think the problems generated by permanent /tmp storage are
> even more confusing than those that come up without it.

Oh yeah?  Please give a concrete example of how not wiping /tmp at boot
can cause data loss.
I'm just asking out of curiosity. No matter what example you give, it is
not relevant for a basic LFS system, because on a basic LFS system, this
is simply not possible.

> > 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. 

Have you had data loss?  I guess no.

> You aren't seriously recommending that you can just leave /tmp without a
> cleanfiles of some sort, are you?

No, I'm not.  The strategy that works best depends on what you're using
your system for. There's a big difference between a server running
unattended (here I agree that /tmp should be wiped at boot) and a desktop
system shut down every evening with only 1 user.


goto doesn't screw up programs.
Programmers screw up programs.

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 mailing list