wombat@ccvaxa.UUCP (09/29/86)
My pet peeve with links: We do some of our development here within "boxes", which are miniature unix filesystems reached via dressed-up chroot calls. The nice thing about them is that you can have complete control over your development environment. The problem is that for each box you set up on a different partition (and almost all of them are on different partitions), you must also install copies of stardard utilities, including most of /bin and /lib plus some of /usr/lib, /usr/bin, and /usr/ucb plus emacs. These have to be real copies, because we don't have nearly enough room on our root disks to put development projects thus making hard links useless, and because symbolic links can't be followed to a target outside of a box. And there goes half the disk space from your box. (Idle speculation says it would be nice if symlinks could reach through a chroot call, but since we also use boxes for security I don't think I could convince other people we should do it.) I disagree that "most uses of links are to connect things in the same directory": We have a project here that uses a stable, common source tree. The developers working on it usually need to change only a few files, but we want them to do it in their own copy of the tree so that they can test it before checking it into the official tree. So they make a copy of the official tree which starts off consisting entirely of directories and hard links to (non-RCS *,v) files in the official tree. When a developer wants to change a file, they first remove the linked version, then get a true copy and edit away. Since the source directory is over 10,000 blocks this saves a lot of disk space. (However, if you ever have to restore the partition from full+incremental dumps you have a really nasty problem on your hands, as we have already discovered.) (You may have guessed from this that our greatest shortage around here is disk space. B-) "Our first order of business will be to find a deranged alchemist, which should not be very difficult. China," said Master Li, "is overstocked with deranged alchemists." Barry Hughart, *Bridge of Birds* Wombat ihnp4!uiucdcs!ccvaxa!wombat
aglew@ccvaxa.UUCP (10/11/86)
> If you are willing to expend large amounts of space, the symlink > loop checks can be made rigorous, e.g., by remembering each symlink > inode and requiring that no one appear twice. The eight-links > limit seems to work well in practice, though, particularly since > symlinks slow name translation markedly. > > Chris Torek As a compromise between counting and remembering paths, don't fail before at least N=8 symlinks, and hash the remainder into bits in as long a mask as you care. The hashing overhead might be worth it if it saves more name translations - AND if you want to have symlink paths longer than N=8 a lot. Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms
jso@edison.UUCP (John Owens) (10/21/86)
In article <1900036@ccvaxa>, aglew@ccvaxa.UUCP writes: > As a compromise between counting and remembering paths, don't fail before > at least N=8 symlinks, and hash the remainder into bits in as long a mask > as you care. The hashing overhead might be worth it if it saves more name > translations - AND if you want to have symlink paths longer than N=8 a lot. > > Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew > 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms Yeah, but then the behavior is unpredictable to the "casual observer". It's easy to say "you can't have more than 8 steps", or even "you can't have a loop, since the kernel remembers the device/inodes traversed". With this method, sometimes you can have more than 8, sometimes not; I don't see how you can be completely reliable with hashing unless you save the actual device/inodes as well, and just use the hashing for speed. John Owens General Electric Company - Charlottesville, VA jso@edison.GE.COM old arpa: jso%edison.GE.COM@seismo.CSS.GOV +1 804 978 5726 old uucp: {seismo,decuac,houxm,calma}!edison!jso