woods@eci386.uucp (Greg A. Woods) (05/25/91)
[I've cross-posted this to comp.bugs.sys5, since it is relevant to all SysVr4.0 versions....] In article <104374@becker.UUCP> bdb@becker.UUCP (Bruce D. Becker) writes: > in Amiga Unix System V Release 4, version 1.1, there > is a misfeature in the "uudemon.cleanup" script: > > SPOOL=/var/spool/uucp ^^^^^^^^^^^^^^^^^^^^^ > [...] > cd $SPOOL > if [ "`pwd`" != "$SPOOL" ]; then > ... mail error message to admin ... > > This has been in the script for perhaps 5-6 years. > > It breaks under SysVr4 because "/var/spool" is a > symbolic link to "/usr/spool"; when the cd is done, > the working directory is now "/usr/spool/uucp" (at > least according to /bin/sh - ksh should succeed). Ah, but the mis-feature is actually with the creature who built the filesystem. /usr/spool should be a symbolic link to /var/spool, not the other way around! /usr/spool is simply a convenience for well trained, but aging fingers. /var/spool is what will be compiled into everything and, as we see above, specified in all scripts. DOWN WITH EXCESSIVE SYMBOLIC LINKS! They are a poor hack, and they cause way too much confusion.... They should only be used when it is *ABSOLUTELY* necessary to have a reference to file on a different filesystem, or *ABSOLUTELY* necessary to have multiple locations/names for a directory. K.I.S.S.! Actually, why does /sbin/sh still have problems with pwd vs. sym-links in the first place? I has no problems on SunOS-4.1.1. > The same problem exists for cd'ing to .Log directories, > since > VAR=/var/uucp > LOGDIR=$VAR/.Log > [...] > cd $LOGDIR/$i > if [ "`pwd`" != "$LOGDIR/$i" ]; then > ... mail error message to admin ... > > and "/var/uucp" is a symbolic link to "/usr/spool/uucp"... This is truly weird. Why did they move the .Log directories into /var/uucp, instead of "leaving" them in /var/spool/uucp? Why didn't they drop the silly '.' prefix from the name if they were moving them somewhere where they don't have to be differentiated from job directories? Another extremely weird thing is that /etc/uucp is just a sym-link to /usr/lib/uucp, instead of containing sym-links to the administrative files in /var/uucp or /var/lib/uucp. Actually, it seems that on SunOS-4.1.1 (which is where I presume the silly /etc/uucp idea came from), the actuall admin files (Systems, uudemon.*, ...) live in /etc/uucp, with a sym-link of remote.unknown to /usr/lib/uucp/remote.unknown, since it too has an admin function. Please, we don't need sym-links of everything admin-related into /etc! -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL
rfg@NCD.COM (Ron Guilmette) (05/26/91)
In article <1991May25.003224.5804@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: > >DOWN WITH EXCESSIVE SYMBOLIC LINKS! They are a poor hack, and they >cause way too much confusion.... They should only be used when it is >*ABSOLUTELY* necessary to have a reference to file on a different >filesystem, or *ABSOLUTELY* necessary to have multiple locations/names >for a directory. K.I.S.S.! If you want to see a really good example of the misuse of symlinks, check out the symlinks underneath /usr/include on a MIPS/os (version 4.51) system. There are several links of the form: filename -> . In other words, there are "circularities" formed from symlinks. If you don't understand why circularities are bad, log onto a MIPS system and then do: cd /usr/include find . -follow -type f -print Be prepared to wait a long long time for it to finish. Alternatively, you could also do: cd /usr/include ls -lR which produces similar results. -- // Ron ("Loose Cannon") Guilmette // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // New motto: If it ain't broke, try using a bigger hammer.
bernie@metapro.DIALix.oz.au (Bernd Felsche) (05/27/91)
In <1991May25.003224.5804@eci386.uucp> woods@eci386.uucp (Greg A. Woods) writes: >DOWN WITH EXCESSIVE SYMBOLIC LINKS! They are a poor hack, and they >cause way too much confusion.... They should only be used when it is >*ABSOLUTELY* necessary to have a reference to file on a different >filesystem, or *ABSOLUTELY* necessary to have multiple locations/names >for a directory. K.I.S.S.! o= o= o= o= o= Symbolic links are essential because System V.4 was designed by a committee. Obviously, nobody could agree, and everybody wanted things in a "familiar" place. Now we're faced with circular references and obfuscated pathnames. One giant leap sideways for mankind. Version 7 is probably an improvement in many ways. -= -= -= -= -= It would have been _far_ better to document the location of everything, and to keep it in a consistent place. -- Bernd Felsche, _--_|\ #include <std/disclaimer.h> Metapro Systems, / sale \ Fax: +61 9 472 3337 328 Albany Highway, \_.--._/ Phone: +61 9 362 9355 Victoria Park, Western Australia v Email: bernie@metapro.DIALix.oz.au
lars@iclswe.icl.se (Lars Tunkrans) (05/28/91)
woods@eci386.uucp (Greg A. Woods) writes: >[I've cross-posted this to comp.bugs.sys5, since it is relevant to all >SysVr4.0 versions....] >In article <104374@becker.UUCP> bdb@becker.UUCP (Bruce D. Becker) writes: >> in Amiga Unix System V Release 4, version 1.1, there >> is a misfeature in the "uudemon.cleanup" script: >> >> SPOOL=/var/spool/uucp > ^^^^^^^^^^^^^^^^^^^^^ >> [...] >> cd $SPOOL >> if [ "`pwd`" != "$SPOOL" ]; then >> ... mail error message to admin ... >> >> This has been in the script for perhaps 5-6 years. >> >> It breaks under SysVr4 because "/var/spool" is a >> symbolic link to "/usr/spool"; when the cd is done, >> the working directory is now "/usr/spool/uucp" (at >> least according to /bin/sh - ksh should succeed). Below is a part of the uudemon.cleanup script from SVR4.0 on DRS6000 Sparc. --------------------------- SPOOL=/var/spool/uucp { stuff deleted } # cleanup funny directories that may have been created in the spool areas cd $SPOOL # check that we are in the correct directory if [ "`pwd`" != "$SPOOL" ] then (echo "uudemon.cleanup: unable to chdir to $SPOOL") | mail $MAILTO continue else for d in $SPOOL/*/*/* do if [ "$d" != "$SPOOL/*/*/*" -a -d "$d" ] then rm -fr $d ----------------------------- As you can see it's essentially the same as on Amiga. >Ah, but the mis-feature is actually with the creature who built the >filesystem. /usr/spool should be a symbolic link to /var/spool, not >the other way around! /usr/spool is simply a convenience for well >trained, but aging fingers. /var/spool is what will be compiled into >everything and, as we see above, specified in all scripts. I agree compleatly /usr/spool is the symbolic link to /var/spool. >DOWN WITH EXCESSIVE SYMBOLIC LINKS! They are a poor hack, and they >cause way too much confusion.... They should only be used when it is >*ABSOLUTELY* necessary to have a reference to file on a different >filesystem, or *ABSOLUTELY* necessary to have multiple locations/names >for a directory. K.I.S.S.! >Actually, why does /sbin/sh still have problems with pwd vs. sym-links >in the first place? I has no problems on SunOS-4.1.1. >> The same problem exists for cd'ing to .Log directories, >> since >> VAR=/var/uucp >> LOGDIR=$VAR/.Log >> [...] >> cd $LOGDIR/$i >> if [ "`pwd`" != "$LOGDIR/$i" ]; then >> ... mail error message to admin ... >> >> and "/var/uucp" is a symbolic link to "/usr/spool/uucp"... >This is truly weird. Why did they move the .Log directories into >/var/uucp, instead of "leaving" them in /var/spool/uucp? Why didn't >they drop the silly '.' prefix from the name if they were moving them >somewhere where they don't have to be differentiated from job >directories? No not here, /usr/spool/uucp/.Log is a symlink to /var/uucp/.Log All .directories are linked to /var/uucp/.directory Presumably to separate the logfiles from the actual spooldirectories. And to keep compatability with old software, it was nessesary to put in the symlinks. >Another extremely weird thing is that /etc/uucp is just a sym-link to >/usr/lib/uucp, instead of containing sym-links to the administrative >files in /var/uucp or /var/lib/uucp. Actually, it seems that on >SunOS-4.1.1 (which is where I presume the silly /etc/uucp idea came >from), the actuall admin files (Systems, uudemon.*, ...) live in >/etc/uucp, with a sym-link of remote.unknown to /usr/lib/uucp/remote.unknown, >since it too has an admin function. >Please, we don't need sym-links of everything admin-related into /etc! No this is not the case either on DRS6000. /usr/lib/uucp/Systems is a symlink to /etc/uucp/Systems. All the BNU/HDB config files are linked in this fasion to achive a situation were we have config data in /etc and program files in /usr, in conformance with the overall philosophy for SVR4 which is to keep out all but the nessesary binaries ( for system startup, i.e. mount fsck a.s.o ) out of the root filesystem. The HDB binaries still live in /usr/lib/uucp, uucico, uucheck and the scripts Uutry and uudemon.xxx is found there. From what has been said above by Bruce and Greg it seems that Commodore has symlinked the New directory-structure to the Old instead of symlinking the Old directory structure to the New SVR4 directories. The symlinks are there to provide compatability for Old software. If one keeps the old directory structure intact and adds on symlinks to make the filestore appear as a SVR4 filestore I sort of think that you have either misunderstood something or just chosen the easiest way out of the fix. And because /sbin/sh finds out where you really are it doesn't work either, as Bruce demonstrated. This is not intended to start a religious war about directories :-) -- _______________________________________________________________________________ Lars Tunkrans Phone +46 (0)76096368 DRS Systems Support DOMAIN Address : lars@iclswe.icl.se UUCP: uunet!mcsun!sunic!iclswe!lars X400: I=L;S=Tunkrans;OU1=SWE0102;O=ICL Data;P=ICL;A=TEDE;C=SE
guy@auspex.auspex.com (Guy Harris) (05/29/91)
>Symbolic links are essential because System V.4 was designed by a >committee. Well, actually, symbolic links are in S5R4 because they're in 4.2andupBSD. >Obviously, nobody could agree, and everybody wanted things >in a "familiar" place. The choice was made in several OSes, not just S5R4, to reorganize the file system somewhat; the first OS to use the new organization was SunOS 4.0, and I think Ultrix may have picked it up as well; 4.4BSD may do so also, as the Berkeley folk were part of the group that decided on the changes. The symbolic links that point to the old places are there for the benefit of both programs and people that haven't converted yet. >It would have been _far_ better to document the location of >everything, and to keep it in a consistent place. Umm, that's an interesting suggestion, but what does it mean? Do you mean that they should have documented the locations a long time ago, and not moved things? Unfortunately, some of those locations weren't ideal, in that, for example, stuff that could be shared by diskless clients and stuff that would be per-client was mixed together on various file systems. One original motivation for the file system reorganization was to make it a bit more pleasant to support diskless clients (that was certainly one of Rusty's motivations for pushing the idea in the first place), so that the root and (later) "/var" file systems would contain stuff that would generally be per-client and the "/usr" file system could contain stuff that would be shareable by all clients. An additional consequence of that split is that, if done right, you can mount "/usr" read-only. Few, if any, changes are entirely devoid of bad consequences, but that doesn't mean few, if any, changes should be made....
breckenr@mpr.ca (Dennis Breckenridge) (05/29/91)
In article <1991May25.003224.5804@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: >[I've cross-posted this to comp.bugs.sys5, since it is relevant to all >SysVr4.0 versions....] > >DOWN WITH EXCESSIVE SYMBOLIC LINKS! They are a poor hack, and they >cause way too much confusion.... They should only be used when it is >*ABSOLUTELY* necessary to have a reference to file on a different >filesystem, or *ABSOLUTELY* necessary to have multiple locations/names >for a directory. K.I.S.S.! > ... > >Please, we don't need sym-links of everything admin-related into /etc! >-- Ah spoken like a true System Fiver, cuz ya don't have em, compain about em! :-) I see you have never run out of space in you spool directory. It is nice to simlink in another dir to get that extra space. I agree that some caution should be used but it is handy. Imagine a network of Sparcs, Suns and Microvaxen, common logins, common work areas... I am sure Greg that they are there just to get you upset that they are not in your release of the vapourware SVR4 on that 3B2 hi hi :-) Dennis S. Breckenridge | MPR Teltech Ltd | Email: breckenr@mpr.ca 8999 Nelson Way | uunet!ubc-cs!mprgate!breckenr Burnaby, BC V5A 4B5 | Telephone: +1 604 294-1471 ext 5516 -- Dennis S. Breckenridge | MPR Teltech Ltd | Email: breckenr@mpr.ca 8999 Nelson Way | uunet!ubc-cs!mprgate!breckenr Burnaby, BC V5A 4B5 | Telephone: +1 604 294-1471 ext 5516
guy@auspex.auspex.com (Guy Harris) (05/30/91)
>Ah spoken like a true System Fiver, cuz ya don't have em, compain about em! :-)
Actually, they appear to be complaining that their System V's *DO* have
them, and are using them fairly extensively....vic@grep.co.uk (Victor Gavin) (05/30/91)
In article <8062@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >The symbolic links that point to the old places are there for the >benefit of both programs and people that haven't converted yet. I thought the main reason that everything was sym-linked was to allow (as you say later) the removing of machine dependent files from a normal file system into somewhere else (local to each machine) so that many machines could share common disks. If this is the case, why such a bogus hack. HP looked at the problem and came up with a general purpose solution that *doesn't* break anything. The technology for this has been given to OSF and it's called Context Dependent Files (CDFs). Basically a file looks, smells and behaves like an ordinary file, but can vary from machine to machine depending on the context (which currently covers things like processor types supported (including sub-classes), name of the current machine, local or remote root file-system and even a default if nothing else matches. With this scheme nothing is broken, everything behaves the way it used to, you don't have to have it if you don't want it, you can make *anything* node independent (like directories, device files...). >One original motivation for the file system reorganization was to make >it a bit more pleasant to support diskless clients (that was certainly >one of Rusty's motivations for pushing the idea in the first place), so >that the root and (later) "/var" file systems would contain stuff that >would generally be per-client and the "/usr" file system could contain >stuff that would be shareable by all clients. An additional consequence >of that split is that, if done right, you can mount "/usr" read-only. See above I'm intrigued as to how diskless clients are supported under this massive sym-linking exercise, since they have no local disks, how do the sym-links point to an area of disk which is for that machine only? NB: With CDFs /usr can't be mounted read-only, but then somehow most machines seem to be able to survive that at the moment. >Few, if any, changes are entirely devoid of bad consequences, but that >doesn't mean few, if any, changes should be made.... *BUT* they should be done in a way that does least harm and if possible in an intuitive, generic and simple way. vic -- Victor Gavin <vic@grep.co.uk||..!ukc!logitek!grep!vic||..!ukc!vision!grep!vic>
ford@amix.commodore.com (Mike "Ford" Ditto) (06/05/91)
In article <104374@becker.UUCP> bdb@becker.UUCP (Bruce D. Becker) writes: > cd $SPOOL > if [ "`pwd`" != "$SPOOL" ]; then > ... mail error message to admin ... > It breaks under SysVr4 because "/var/spool" is a > symbolic link to "/usr/spool"; In article <1991May25.003224.5804@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: > Ah, but the mis-feature is actually with the creature who built the > filesystem. /usr/spool should be a symbolic link to /var/spool, not > the other way around! Although it's true that the symlink would be more correct the other way around, the bug is still in the script. A script which depends on the difference between /bin/pwd and the sh builtin is non-portable and poorly written, IMHO. The check in the uucp cleanup script is stupid anyway because a failed cd terminates a script (and always has), and even if it didn't, the script would be better written as: cd $SPOOL || { ... mail ...; exit ...; } > DOWN WITH EXCESSIVE SYMBOLIC LINKS! They are a poor hack, and they > cause way too much confusion.... Hear, hear! > Actually, why does /sbin/sh still have problems with pwd vs. sym-links > in the first place? I has no problems on SunOS-4.1.1. I see no problems in sh that are not inherent in the concept of BSD symlinks. > This is truly weird. Why did they move the .Log directories into > /var/uucp, instead of "leaving" them in /var/spool/uucp? To be consistent with the newfangled SunOS/SVR4 scheme: /var is for node-specific files that must be writable and may "grow" and need to be trimmed. /var/spool is for node-specific transient files that will be deleted after they are processed. /etc is for node-specific configuration files. /usr/lib is for shared, read-only, archetecture-specific libraries and programs. Amiga Unix v1.1 had an unnecessarily non-standard uucp directory setup and v2.0 will make much more sense. A "proper" SVR4 uucp directory setup has the following four distinct directories: /var/uucp /var/spool/uucp /etc/uucp /usr/lib/uucp The only symlinks that should exist are the ones that cause files that have been moved to a new directory also to be available under their old names. So, since Systems is now in /etc/uucp, there is /usr/lib/uucp/Systems -> /etc/uucp/Systems but there is *NO* /etc/uucp/uucico -> /usr/lib/uucp/uucico since uucico's official place is and always has been /usr/lib/uucp; no program will expect it to be in /etc/uucp. > Why didn't > they drop the silly '.' prefix from the name if they were moving them > somewhere where they don't have to be differentiated from job > directories? I don't know; I wish they had. > Another extremely weird thing is that /etc/uucp is just a sym-link to > /usr/lib/uucp, instead of containing sym-links to the administrative > files in /var/uucp or /var/lib/uucp. /etc/uucp should have been a distinct directory but it shouldn't contain any symlinks except for remote.unknown -> /usr/lib/uucp/remote.unknown. -=] Ford [=- "The heart and the mind on (In Real Life: Mike Ditto) a parallel course, never ford@amix.commodore.com the two shall meet." uunet!cbmvax!ditto -- Indigo Girls ford@kenobi.commodore.com
guy@auspex.auspex.com (Guy Harris) (06/08/91)
>I'm intrigued as to how diskless clients are supported under this >massive sym-linking exercise, since they have no local disks, how do >the sym-links point to an area of disk which is for that machine only? Easy. Each diskless machine has its own root file system, the root of which is a per-machine directory on a file system on its server, e.g.: bootme% /etc/mount alpha1-e4:/export0/root/bootme on / type nfs (rw) ... >NB: With CDFs /usr can't be mounted read-only, but then somehow most >machines seem to be able to survive that at the moment. There's lots of things you can survive without, but it may be convenient to have "/usr" read-only.