/tmp

[George Robbins]

In article <2803 at helios.ee.lbl.gov> envbvs at epb2.lbl.gov (Brian V. Smith) writes:
> In article <10390 at smoke.BRL.MIL>, gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
> > In article <5712 at lynx.UUCP> m5 at lynx.UUCP (Mike McNally) writes:
> > >What bad bad things happen if I symbolically link /tmp to /usr/tmp?
> > 
> > As you suggested later, the main thing to worry about is that /tmp
> > is probably required before the /usr filesystem is mounted.
> 
> We haven't had any problem with our /tmp directory sym-linked to
> /usr/tmp.from.root (as we call it).  It doesn't seem that it is needed
> during booting.

One possible area of concern would be if you are in a situation where
fsck uses/needs a workfile to check your larger filesystems.  You might
note that in this case, using a workfile in /tmp, where /tmp is just
a directory in the root is not a very good idea - you're better off
putting the file in a partition the gets check first (perhaps a /tmp
partition) or having an itty-bitty partition that is used only as a
fsck workfile.

In general, /usr/tmp isn't an idea that maps comfortably onto larger
systems all that comfortably unless it happens to be the mount point
for a "work" partition.  There's an implicit assumption, that /usr is
the filesystem where the user directories live, and thus a good place
to put big work files.  Unfortunatly, user and backup administration
is much simpler if user directories are in their own filesystem, and
/usr is a "system" directory.

In this case, you may be better off with a /tmp filesystem, and no /usr/tmp.
In the olde days, there was no requirement that you have a /usr/tmp -
programs could try to put files there if it existed and if not were then
expect to try again in /tmp.  I don't know if this is still a safe
assumption or not.

Note that most of the problem goes away with BSD, since symbolic links
allow a fairly arbitrary mapping of the conventional filesystem
hierarchy onto the underlying partitions.
-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr at uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)