larry@nstar.UUCP (Larry Snyder) (03/26/90)
Is there a way to modify the kernel (386/ix) to increase the length of file names to 18 characters? -- ...!iuvax!ndmath!nstar!larry -or- larry@nstar
rcd@ico.isc.com (Dick Dunn) (03/27/90)
larry@nstar.UUCP (Larry Snyder) writes: > Is there a way to modify the kernel (386/ix) to increase the length > of file names to 18 characters? No. It's not theoretically impossible; it's just highly impractical. And you'd need source for a fair bit of the kernel. Why 18??? The current (also ancient, time-honored) limit of 14 is used because it is two less than a power of two; the two remaining bytes contain the i-number of the file. This lets a whole number of (fixed-size) directory entries fit in a file-system block. The next logical increase, if you were to retain the current structure, would be a name limit of 30 bytes. That wouldn't be terribly hard to do, but it would be tedious... and you'd need kernel source to do it. Even if you could make such a change, the conversion would be painful, since you'd be introducing a new file system type. There are some "genesis" problems (booting old style to install new, converting old to new). When you finished, you'd have a file system which would be incompatible with both old AT&T 14-fixed-length style and BSD flexname- style. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Relax...don't worry...have a homebrew.
cpcahil@virtech.uucp (Conor P. Cahill) (03/27/90)
In article <511363@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes: >Is there a way to modify the kernel (386/ix) to increase the length >of file names to 18 characters? Not if you are an end-user. If you had source you could attempt it, but you would run into problems all through the system when you find programs that read a directory assuming it is 16-bytes per entry. Even the smart programs that can recognize the difference between BSD directories and System V directories would be fooled and break. Even if I had source, I would try to add source for the BSD file system before I tried extend the System V file system to support 18 character file names. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (03/28/90)
In article <511363@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes: >Is there a way to modify the kernel (386/ix) to increase the length >of file names to 18 characters? Yes, in fact AT&T has done it and called the new kernel Sys V.4 :-).
guy@auspex.auspex.com (Guy Harris) (03/28/90)
>Even the smart programs that can recognize the difference between BSD >directories and System V directories would be fooled and break. *Truly* smart programs use the directory library, which means that, since the new file system would (unless truly stupid) implement "getdents()" correctly, they wouldn't be fazed in the least by such a file system. >Even if I had source, I would try to add source for the BSD file system >before I tried extend the System V file system to support 18 character >file names. No argument there.
root@nebulus.UUCP (Dennis S. Breckenridge) (03/28/90)
In article <_+B$CS+@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: > In article <511363@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes: > >Is there a way to modify the kernel (386/ix) to increase the length > >of file names to 18 characters? > > Yes, in fact AT&T has done it and called the new kernel Sys V.4 :-). Are you sure? I had a look at the AT&T software at a trade show and all I saw was the UFS file system type. I did notice symlinks are there but not long file names. It may be released in the final product. Also have a look at your sendmail.cf your header has a typo! -- ----------------------------------------------------------------------------- Dennis S. Breckenridge (604) 277-7413 dennis@nebulus.uucp VE7TCP EMACS: Eight Megabytes And Constantly Swapping! -----------------------------------------------------------------------------
guy@auspex.auspex.com (Guy Harris) (03/29/90)
>>Is there a way to modify the kernel (386/ix) to increase the length >>of file names to 18 characters? > >Yes, in fact AT&T has done it and called the new kernel Sys V.4 :-). No, they increased it to 255 characters, actually. (For those not aware of it, S5R4 includes both the V7 file system traditionally used by S5, with the 14-character maximum on file names, and the 4.3BSD file system, with a 255-character maximum on file names. Both plug into the Virtual File System mechanism, derived from the SunOS 4.x one.)
larry@nstar.UUCP (Larry Snyder) (03/29/90)
> No, they increased it to 255 characters, actually. (For those not aware > of it, S5R4 includes both the V7 file system traditionally used by S5, > with the 14-character maximum on file names, and the 4.3BSD file system, > with a 255-character maximum on file names. Both plug into the Virtual I assume that one can mix and match (have both enabled at one time). -- ...!iuvax!ndmath!nstar!larry -or- larry@nstar
cpcahil@virtech.uucp (Conor P. Cahill) (03/29/90)
In article <511373@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes: >> No, they increased it to 255 characters, actually. (For those not aware >> of it, S5R4 includes both the V7 file system traditionally used by S5, >> with the 14-character maximum on file names, and the 4.3BSD file system, >> with a 255-character maximum on file names. Both plug into the Virtual > >I assume that one can mix and match (have both enabled at one time). You can mix and match file systems on the same system. That is the whole purpose of the "virtual File System" code (i.e. support for multiple file system types). -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
guy@auspex.auspex.com (Guy Harris) (03/30/90)
>I assume that one can mix and match (have both enabled at one time).
Yes, you can plug in as many file system types as fit in physical memory
(i.e., if you have 128 MB worth of file system type code, you may have a
problem :-)), and at least at the kernel level they should all work.
The file systems I know of that come with S5R4 are S5FS (the old
V7-derived file system), UFS (the new 4.3BSD-derived file system), NFS,
RFS, "/proc", and "/dev/fd"; there may be others. Silicon Graphics, for
instance, would probably provide their Extent File System if, as, and
when they do an S5R4 port.
There are also mechanisms for allowing multiple file system types to be
handled by "mount", "fsck", etc., involving replacing those programs
with "drivers" that run file-system-specific versions.
So unless somebody's screwed something up, you should be able to run
both. The only headaches I expect would be those involved with booting;
I don't know whether the various boot programs will be able to read
"/unix" off of either an S5 or UFS file system, or whether they'll only
be able to cope with one or the other.dcm@moria.UUCP (David C. Miller) (04/06/90)
In article <1990Apr2.230603.2687@i88.isc.com> stevea@i88.isc.com (Steve Alexander) writes: >The version of V.4 that I'm using only seems to be able to boot from >S5 or the BFS (boot file system, called /stand). I couldn't boot new kernels >from a UFS root, they had to be copied to /stand. > >-- >Steve Alexander, Software Technologies Group | stevea@i88.isc.com >INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea What you have seen is the motivation behind the creation of the BFS file system. The BFS filesystem allows you to have a root filesystem of any type without the bootstrap having to know how to read it. I'm guessing that the boot off of S5 was done with a floppy? I'm not familiar with the i386 port, just the 3B2. On the 3B2 you can boot off the /stand (BFS) filesystem or off the floppy (BFS or S5). Without BFS, you would need to rewrite the bootstrap every time you added a new filesystem type. -- David C. Miller ...!tsdiag!ka2qhd!moria!dcm