mangler@cit-vax.Caltech.Edu (System Mangler) (10/20/86)
In article <21127@rochester.ARPA> ken@rochester.UUCP (Comfy chair) writes: > I don't like symbolic links, there are some warts, like having to check > for looping, but I can't think of anything better. Warts... you can't chmod, chgrp, utime, or link them. The access time never means much, because doing an "ls -l" to see it has the side effect of changing it. Symbolic links are too expensive to use freely. They take up an inode and 1K of disk space, just to hold a few characters. They carry all the baggage of a regular inode (atime, mtime, links, owner, group, mode) but you can't make proper use of any of it. Since Berkeley was making directory entries variable length anyway, why didn't they just make symbolic links a variant type of directory entry, containing a string instead of an inode number? They might be twice the size of a normal directory entry, but the time saved in not having to read another inode would be a big win. Don Speck speck@vlsi.caltech.edu {seismo,rutgers}!cit-vax!speck
guy@sun.UUCP (10/20/86)
> Since Berkeley was making directory entries variable length > anyway, why didn't they just make symbolic links a variant > type of directory entry, containing a string instead of an > inode number? They might be twice the size of a normal > directory entry, but the time saved in not having to read > another inode would be a big win. Because that would have required non-trivial changes to programs that read directory entries, in order that they understand this new type of directory entry. The 4.2BSD file system changed the format of directory entries, but didn't really change their meaning; as far as an application reading the directory is concerned, they are still <inumber, name> pairs. Converting a program to use the directory library is a mechanical, albeit not automated, operation. If this new "indirect" directory entry were introduced, the conversion process would no longer be mechanical. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
mangler@cit-vax.Caltech.Edu (System Mangler) (10/26/86)
In article <8313@sun.uucp>, guy@sun.UUCP writes: > > why didn't they [Berkeley] just make symbolic links a variant > > type of directory entry, containing a string instead of an > > inode number? > > Because that would have required non-trivial changes to programs that read > directory entries, Many directory-reading programs (ls, tar, find) had to gain explicit knowledge of symbolic links anyway, the changes were even user-visible. Don Speck speck@vlsi.caltech.edu {seismo,rutgers}!cit-vax!speck
guy@sun.UUCP (10/27/86)
> Many directory-reading programs (ls, tar, find) had to gain explicit > knowledge of symbolic links anyway, the changes were even user-visible. And many didn't. If a new type of directory entry were added, *every* directory-reading program would have to gain explicit knowledge of symbolic links, and the change would be more complicated (with symbolic links as they are, the *directory-reading code* didn't have to change, other than mechanically replacing explicit "read"/"fread"/whatever calls with "readdir" calls, etc.). Furthermore, "fsck" would have to be taught about these new kinds of directory entries (not just about new kinds of inodes, as was the case with the current symbolic link implementation), as would a bunch of other utilities that know about file system formats. I presume they just decided the added benefits weren't worth the hassle. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)