NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/os/minix/4977

Text File | 1992-12-23 | 3.6 KB | 76 lines

Newsgroups: comp.os.minix
Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!torvalds
From: [e-mail] (Linus Torvalds)
Subject: Re: Long filenames
Message-ID: <[e-mail]>
Organization: University of Helsinki
References: <[e-mail]>
Date: Wed, 23 Dec 1992 13:13:13 GMT
Lines: 65

In article <[e-mail]> [e-mail] (Chris Hanson) writes:
>Hi!  Can anyone point me to some info (or tell me themselves) on how to
>implement long filenames for minix?  [I know someone's done it -- one
>of the dudes in the 'MINIX vs LINUX' discussion mentioned it.]  I'm
>thinking that 30 chars or 62 chars shouldn't be that hard (we'd be
>keeping a dir_entry at an even multiple of 16 bytes), but I know it'll
>involve more than just recompiling the kernel with MAX_NAME changed.

The problem shouldn't be so much the kernel as all the binaries you are
using: changing the directory structure will break everything that reads
directory entries - this includes important binaries like 'ls'
(obviously), the shell (for filename globbing, name completion etc),
'make', etc.

>Will I need to make new filesystems and move everything to them?  Or is
>a compatibility hack (such as puting an optional fstype flag or a
>different magic number in a device's superblock to tell whether it has
>long or standard pathnames) trivial?

I'd go for the compatability hack: creating a new filesystem from
scratch for the new kernel is simply too painful (as well as making
debugging pretty mcuh impossible...  much easier to start off with just
one partition with the extended setup, and test out all the new binaries
on that one first).  I'd also suggest you add a "readdir()" system call
while you are at it, which checks the magic number and returns the
correct type of directory entry.  That way binaries compiled to use it
will be able to function correctly on both the new and old type of
filesystem.

There are a couple of alternatives you could do:

 (a) go for a complete vfs (virtual filesystems) interface.  This would
make it possible to later add totally different types of filesystems.
It's more general, but it's also a lot more coding.  This is the
approach linux uses, and it gives the possibility to mount msdos etc
filesystems transparently.

 (b) do the long filenames by fooling around with several consecutive
minix-type directory entries.  Depending on how you do it, you can make
old binaries see only th first characters of a extended filename, while
new binaries see them all.  Besides, this means you won't waste a full
64-char direntry for short files, but instead use several entries only
when necessary.  The downside is that it's a bit more work in the
kernel.

The directory entries in (b) could be made to work by using a magic
cookie at the end of a filename to mean that the filename continues in
the next entry (which has a inode nr of 0 to make old programs ignore
it).  It could look something like this:

file "really_long_name", use '\000\377' as continuation marker:

    .word inode_number
    .byte 'really_long_\000\377'    /* first 12 chars */
    .word 0x0000            /* next entry is a continuation */
    .byte 'filename\0'        /* rest of the filename */

This can be extended to any filename length, and old programs will see
only the first 12 characters, but they should work otherwise.  I think
somebody implemented something like this.  Patches, anybody? Naturally,
you'd have to make sure that none of your current filesystems happen to
have the '\000\377' sequence at the end of a directory entry, but that
should be simple enough.

        Linus