home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / minix / 5275 < prev    next >
Encoding:
Text File  |  1993-01-27  |  2.5 KB  |  65 lines
  1. Path: sparky!uunet!news.univie.ac.at!scsing.switch.ch!univ-lyon1.fr!ghost.dsi.unimi.it!rpi!uwm.edu!caen!batcomputer!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!werple.apana.org.au!hal9000!monty!newton
  2. From: newton@monty.apana.org.au (Mark Newton)
  3. Newsgroups: comp.os.minix
  4. Distribution: world
  5. Subject: Re: Another MacMINIX 'suggestion'
  6. References: <1jqrr5INNbbo@usenet.INS.CWRU.Edu>
  7. Message-ID: <9301267907@monty.apana.org.au>
  8. Organization: APANA South Australia - State mail hub
  9. Date: Tue, 26 Jan 93 16:15:07 +1030
  10. Lines: 53
  11.  
  12. bf795@cleveland.Freenet.Edu (James Abendschan) writes:
  13. > >On longer names: the files limits.h, unistd.h and ar.h all have a
  14. > >#define whose name contains NAME_MAX. Can I increase this value 
  15. > >without screwing things up? Specifically, would I then have a different
  16. > >flavor of directory entry (and therefore a different flavor of 
  17. > >filesystem?)
  18. >  
  19. > Actually, I think 13 chars is a POSIX requirement or some such.  I
  20. > don't know about this.  It should work though, I suppose.
  21.  
  22. Changing NAME_MAX won't make a whole lot of difference.  The structure
  23. of a directory is defined in /usr/include/sys/dir.h:
  24.  
  25. #ifndef DIRSIZ
  26. #define    DIRSIZ    14
  27. #endif
  28.  
  29. struct direct {
  30.   ino_t d_ino;
  31.   char d_name[DIRSIZ];
  32. };
  33.  
  34. Each directory entry has space for a 14 character filename (not 13
  35. chars; the null-terminator isn't necessary), no matter what NAME_MAX
  36. is set to.
  37.  
  38. Of course, changing DIRSIZ will break all your existing directories,
  39. since directory reading routines frequently do things like
  40. read(fd, buf, sizeof(struct direct)).  Changing the size of struct
  41. direct without altering the on-disk copies of the directory structure
  42. would be a very bad idea indeed.
  43.  
  44. (deem Linux vfs included :-)
  45.  
  46. > >I'm also looking for a ln that handles links to directories (not 
  47. > >just for the super user) as well as symbolic links. Does anyone here
  48. > >have this? If not: what kinds of things and which files will I have
  49. > >to deal with?
  50. >  
  51. > There was a symlink program on one of the ftp archives.  My FS isn't
  52. > big enough to require symlinks, so I haven't tried it.  Look for
  53. > symlink.tar.Z or something on plains.nodak.edu, under ibm or oz-utils ..
  54. > I think that's where I saw it.
  55.  
  56. There's a version of it on Warren Toomey's archives, with two patch
  57. files.  I'm running it now, and haven't had any problems with it.
  58.  
  59.    - mark
  60.  
  61. --------------------------------------------------------------------
  62. Self-control:  The ability to eat          newton@monty.apana.org.au
  63.     only one peanut.                                     Mark Newton
  64. --------------------------------------------------------------------
  65.