Marc S. Jensen mjensen at metronet.com
Mon Oct 28 07:08:20 PST 2002

I agree that, from a user-perspective, it's better to use ~/tmp for your own
temporary files.  But, there are many computing environments (academic,
mostly) where they actually use and enforce restrictive disk quotas for all
their users -- and /tmp can give users a way to temporarily use more disk
space than they've been allotted.

But this really shouldn't be that big an issue.  I mean, when you build your
LFS system, you *know* whether you're planning on using it as your personal
hobby system, your workstation, or as a busy multi-user server.  If it's
your own machine, you can setup /tmp any way you like it.  If you're
administering a busy server, you're (hopefully) knowledgeable enough to
think of a way to inform all the users about your server's /tmp policy.

If LFS is intended to be a "base" linux system, there's no reason for it to
automatically flush /tmp.  Almost by definition, the only people who would
ever be hurt by /tmp files are ones who have progressed to BLFS stuff like
X; and, besides, if you know enough to have reasons for flushing /tmp, you
also know enough to devise a way of doing it.  I personally keep a ton of
stuff in /tmp, and I would much rather manually clean out a lockfile once in
a while than lose my favourite storage space.  But then, my LFS box is only
used by me.



Gintautas wrote:

> Hello,
> As far as I can see, this /tmp cleaning issue sparked an interesting
> discussion, and I thought it might be interesting for you to hear my
> opinion.
> Personally, I don't think /tmp should be used actively by the user.
> Excuse me for a poor and flame-attracting analogy, but I see /tmp as
> C:\WIN{D|BL}OWS\TEMP. For those (few) of you stuck with windows, I
> suppose you aren't using it for temporarily placing your files, etc.
> It's a directory for the system, where e.g. setup self-extractors unzip
> or programs put their swap-files and other temporary (usually deleted
> after exiting the program) stuff, and normally you shouldn't fiddle
> around with it except to clean all the trash up. And it's totally OK to
> clear it in the boot process.
> I can hear the cries that "/tmp" is quick to type and "C:\WINDOW~1/TEMP"
> isn't. That might be one of the causes of the correct users' attitude to
> that directory :-) However, I'd like to propose a method I use.
> I create a tmp directory in my home-dir and use that. It isn't much
> longer to type ("~/tmp" instead of "/tmp"). First of all, it's more
> multiuser-friendly: I don't like the idea of working in a directory
> where other users are working too, it could cause confusion and is not
> practical.  Another advantage of this if you have a separate /home
> partition (like I do), it could save time, because in my system stuff
> usually goes to 3 places: the unknown voids of /dev/null, the huge tip
> of /usr or /usr/local or /opt/something, or, most probably somewhere in
> my home directory, and that's where the advantage is -- when you move
> files, they do not have to be copied over and then deleted, just
> a rename is enough. In addition, some people like to partition their
> disks so / is separate, in which case it is usually small (up to 100MB),
> while usually abundant space is reserved for /home, so there's the
> decreased danger of running out of disk space. In conclusion, I don't
> see any real disadvantages of this method.
> There is one special case, when quotas are involved. I am completely
> incompetent in this field, but I have the impression that in some
> systems quotas are imposed on home directory sizes, and if you need some
> extra [very] temporary space, you may write to /tmp. My counter-argument
> to this would be that you should never expect anything in /tmp to live:
> let's say the administrator sees that diskspace is approaching critical
> levels and he sees that /tmp usage is high (be it you who filled it or
> not), s/he might just clean /tmp without much pain.  If you need to put
> persistent data, go ask to increase your quota. If that is refused,
> then, well, tough luck.
> My proposed solution would be to make the scripts clean /tmp, but write
> a warning about that IN CAPITAL LETTERS in the book (and you could also
> include simple instructions on how to bypass this cleaning-up on boot in
> case something goes very wrong). Those who don't like this behaviour may
> edit and comment out the "offending" commands, those who don't know
> shell scripting will have to learn the right way of doing things. And I
> don't really give a damn about those who don't read the book and so
> might miss this warning.
> --
>  Gintautas
> --
> Unsubscribe: send email to listar at linuxfromscratch.org
> and put 'unsubscribe lfs-dev' in the subject header of the message

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