home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.19 / text0025.txt < prev    next >
Encoding:
Internet Message Format  |  1990-05-17  |  1.2 KB
  1. From: srg@quick.COM (Spencer Garrett)
  2.  
  3. I don't know if this is the proper forum in which to discuss this issue,
  4. but it seems to me that we're about to codify a poor implementation of
  5. the concept of symbolic links.  IMHO symbolic links shouldn't have
  6. a format code at all, since they shouldn't be inodes.  They make
  7. infinitely more sense when treated as directory artifacts - i.e. a
  8. directory entry either points to an inode or it supplies some more
  9. path information to be used in resolving the request.  This eliminates
  10. all the silliness about what permission bits on symbolic link inodes
  11. mean, for instance.  Here's the directory structure I use in my own OS.
  12.  
  13.  
  14.  
  15. /* Directory entries are null-padded to a multiple of 4 bytes.
  16.  * reclen and namlen fit in the first 4 bytes so that any amount
  17.  * of free space can be described in a consistent manner.
  18.  *
  19.  * namlen == 0    => entry is free, reclen describes all adjacent free space
  20.  * namlen != 0    => entry in use, reclen describes only this entry
  21.  *    ino == 0  => symbolic link (path follows name)
  22.  *    ino != 0  => file
  23.  */
  24.  
  25. struct direct {
  26.     unsigned short    reclen;
  27.     unsigned short    namlen;
  28.     unsigned long    ino;
  29.     char        name[DIRBLKSIZ-12];
  30. };
  31.  
  32. Volume-Number: Volume 19, Number 26
  33.  
  34.