craig@bacchus.esa.oz.au (Craig Macbride) (03/13/91)
In <350@mixcom.COM> sysop@mixcom.COM (System Operator) writes: >If you make /tmp a separate file system rather than >leaving it a directory in the root file system, you >must unmount /tmp before using SCO's "custom" to install >and deinstall packages. >Some installation scripts create links in /tmp. If >/tmp is a file system, this will fail, though the script >may not notice that and continue. (A link will fail in this case >since SCO UNIX cannot create links across file systems. This >is a characteristic of UNIX System V, not a "feature" created by SCO.) Pathetic, isn't it? The same sort of thing can happen when you tell ISC's admin shell to create a /tmp partition amongst others: It goes and writes files to /tmp and wonders why they've disappeared when it mounts the new /tmp over them. ISC and SCO are by no means the only vendors who have managed to do these types of things. 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. -- _____________________________________________________________________________ | Craig Macbride, craig@bacchus.esa.oz.au | Hardware: | | | The parts of a computer | | Expert Solutions Australia | which you can kick! |
ignatz@chinet.chi.il.us (Dave Ihnat) (03/14/91)
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