Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!cs.uoregon.edu!ogicse!intelhf!ichips!iwarp.intel.com!gargoyle!chinet!ignatz
From: ignatz@chinet.chi.il.us (Dave Ihnat)
Newsgroups: comp.unix.sysv386
Subject: Re: Installations when /tmp is a separate file system.
Summary: Mountable /tmp is the aberration here...
Keywords: isc sco unix packages install deinstall bug danger
Message-ID: <1991Mar13.181556.20693@chinet.chi.il.us>
Date: 13 Mar 91 18:15:56 GMT
References: <1991Mar06.060331.6849@kithrup.COM> <350@mixcom.COM> <1922@bacchus.esa.oz.au>
Sender: Dave Ihnat
Organization: Analysts International Corporation, Chicago
Lines: 61

In article <1922@bacchus.esa.oz.au> craig@bacchus.esa.oz.au (Craig Macbride) 
quotes <350@mixcom.COM> sysop@mixcom.COM (System Operator) concerning problems
encountered with SCO's custom when the /tmp directory is a separately mounted
filesystem, and with some installation scripts which expect to link to files
in /tmp (along with a mild grumble about System V not supporting cross-
filesystem symbolic links).  Crag further mentions that ISC's admin shell
gets ill when /tmp is mountable, and comments that:

> It is amazing that when linking to, mounting or unmounting /tmp, which
> is very likely to be on a separate file system, they don't do any sort
> of checking.

This isn't a flame, but it *is* a bit of instruction about why the some of
the Unix filesystem directory conventions exist, my belief about why they
ever became muddied, and why violating them is starting to bite us.

Originally, the reason for having directories on the same filesystem under
root was to provide a single-user environment for the administrator
*before* mountable filesystems were checked and running; thus, the directories
/etc, /lib, /bin, /dev, and /tmp should always be on the same filesystem.
The further assumption was that, once the filesystems were mounted, at least
one--/usr--could be counted upon to be present, and to provided the additional
utilities and packages that a full system would offer.  Thus, you find the
cognates /usr/lib, /usr/bin, and /usr/tmp.  (Notice that there's really
no need to duplicate /etc and /dev, so it wasn't.)

 It was widely understood by developers that you didn't write general
applications to use /tmp, as the root filesystem usually was kept as small
as possible; that's what /usr/tmp was for, and it quite often was a separately
mounted filesystem in its own right.

Much of the reason for this administrative scheme fell by the wayside as
the use of single Winchester drives, with logical partitions, became common.
I've found that, for most clients, it's quite rare to actually run in
single-user mode at all.  The systems are simply set up to fsck the root,
fsck all the partitions, and then mount and go.  Often, there was little
benefit with a single drive to over-partitioning.

Today, users are again beginning to encounter mountable media that
are actually different devices--more real disks on a machine, mountable optical
filesystems, etc.  And now we're really starting to recreate the environment
that caused the original organization in the first place (yes, with faster,
larger, newer technology, but...)  Those who became lax in keeping the
single-user scenario in mind are getting bitten by scripts or programs that
didn't, and expected that /tmp would be maintained as it originally was
intended.

As an aside on the lack of cross-filesystem links, originally the Ivory Tower
team (K&R&T et. al.) actually addressed this; they were trying to keep Unix
simple and small, and there are some very real and significant complications
added by trying to keep track of cross-filesystem links, so they deliberately
did not support these, and explicitly said so.  It is, then, an artifact not
simply of System V but of all AT&T-derived Unix systems.  The folk at
Berkeley didn't see this as part of their mandate, and implemented it (and
yes, it complicated life.)  In this day of RFS, NFS, and networks, a simple
cross-filesystem link doesn't seem so complicated any more; and that's one
reason (along with its general utility) SVR4 has abandoned the simpler model.

		Dave Ihnat
		ignatz@homebru.chi.il.us (preferred return address)
		ignatz@chinet.chi.il.us