From: SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 1-JUL-1993 12:50:36.47 To: EVERHART CC: Subj: RE: RMS subdirectories Message-Id: <9307010345.AB20504@uu3.psi.com> Date: Wed, 30 Jun 93 23:31:27 EDT From: Jerry Leichter To: INFO-VAX@sri.com Subject: RE: RMS subdirectories X-Vms-Mail-To: UUCP%"EVERHART@arisia.gce.com" The RMS code does not lend itself to any simple patch to bump the number of subdirectories. The value is coded as an assembly parameter FWA$C_MAXSUBDIR but also there are various buffers big enough to hold each subdirectory name. This means 16 buffers of 39 chars each for the current max of 7 subdirs. Evidently RMS is coded real cautiously so that IT can support the full length path specification, even if nothing else should. There are many tests of these things, but significantly deepening the depth of permitted trees would require larger buffers or a restriction on total path length in addition. This wouldn't bother me particularly (who could type such long names anyway?) but represents some change in design for RMS. The code seems to be entirely in RMS, not in the underlying XQP, where subdirectory access is handled. It ought to be possible certainly to handle deeper trees in a reader program. Mind, I haven't analyzed the code in any detail; it may be that some patch could be worked up, just bashing many places, but it appears that reassembly would allow this to be done. Since most VMS boxes these days are larger (particularly in the AXP space) I would suspect it's a good idea to bump from 8 levels to something higher like maybe 32 or so. There could be a restriction stated that would say that many applications could support only x character pathnames and that pathnames of over, say, 255 characters were not guaranteed to work for all components, and such a system would still be more useful than the current one. NO component of VMS can possibly handle file specifications that exceed 255 characters since the file specification length fields in the NAM block are bytes. The only way to support longer specifications would be to change the RMS interface - a major undertaking. The length of the file specification isn't the issue in multiple levels of directories; even today, the limitation is on the total length of the specification, not on any of the components. Consider that a nest of only 5 levels of directory, each 39 characters long; plus a file name and type each 39 characters long; already places you at 273 characters - and that's without the syntactic markers like the brackets, or the device name or file version number, all of which would have to appear in the expanded specifica- tion. Unfortunately, a decision about data structures made many years ago when memory was expensive and disks were small is now rather difficult to get away from. It's showing up in one entirely different context: Phase V DECnet. An OSI node name can itself be (much) more than 255 characters long! BTW, for anyone who wonders how Unix manages to get away with arbitrary nesting depths: The design is entirely different. In Unix, file paths as such exist only OUTSIDE the kernel. When you present a path to the kernel - in the open call, say - the kernel (routine namei, to be specific) translates one component at a time, updating a single storage area that is sufficient to hold one inode (essentially the equivalent of one file header). One pass of namei starts with the current inode - a directory - and a name, and replaces the inode by the inode named in that directory. The initial value for the inode at the beginning of the search is either the current directory - which is stored as an inode, NOT as in VMS as a string - or the root inode (which can of course always be found). All the kernel needs is space for one inode per process (for its current directory), and one temporary working area inode (since the Unix kernel is single-threaded in traditional implementations it doesn't have to worry about multiple processes doing namei's at once). An interesting side-effect of this implementation is that extracting the current directory as a path is a non-trivial operation: Unix has to start with the inode and create a path that leads to it. This is essentially like the VMS LIB$FID_TO_NAME operation. -- Jerry