NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/os/linux/10076

Internet Message Format | 1992-09-08 | 3.5 KB

Path: sparky!uunet!mcsun!corton!jussieu!card
From: [e-mail] (Remy CARD)
Newsgroups: comp.os.linux
Subject: Re: DR-DOS and linux boot, 14 char filenames
Message-ID: <[e-mail]>
Date: 7 Sep 92 13:06:06 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (Le Facteur)
Organization: Laboratoire MASI - Universite Pierre et Marie Curie - Paris - France
Lines: 64
Nntp-Posting-Host: ares.ibp.fr

In article <[e-mail]> [e-mail] (Jim Winstead Jr.) writes:
>In article <[e-mail]> [e-mail] (Kevin J. Cummings) writes:
>>In article <[e-mail]>, [e-mail] (Jan Lien) writes:
>
>>> Where do I find the stuff for more than 14 characters in linux
>>> filenames?    Does it work properly?
>>
>>the Extended File System (EFS) is in ALPHA test and is a part of the latest
>>kernel.  Use with caution.  They are promising to change the disk part
>>of the files system RSN (real soon now) in an incompatible but upgradeable
>>fashion.  Personally, I can work around most of the 14 char limit and will
>>wait for at LEAST a BETA test of EFS before I convert over.
>
>Well, even though things like the MS-DOS fs, Extended fs, and LILO are
>all called 'alpha test', they've all been quite solid in my
>experience.  There's no need to scare anyone off.  :)

    Well, it is good to read that at least some people are happy with
the ext fs.  Note that, for people not using the ext fs, I would recommend
to wait until the release of the new ext fs which should be better.

>
>>By the way, in case any of the EFS team is listening, 256 character filenames
>>is overkill.  32 characters would have probably handled 95% of the problems out
>>there (not accounting for C++ generated names).  But I'm not complaining!
>
>Yes, but someone would have complained when they wanted a 34-character
>name and couldn't do it.  :)  Ideally, the name length should be
>stored in the directory along with the name, instead of a fixed-length
>string....

    Yes, the EFS team (me in fact ;-) ) is listening.  In the ext fs,
file name length is stored in the directory.  A directory entry is a record
containing :
    - the inode number,
    - the size of the record,
    - the size of the file name,
    - the name itself.

    With this structure, directory operations (find_entry, add_entry) are
a bit slower than in the minix fs (where directory entries have a fixed size) but
it's the price to pay to get longer file names without disk space waste.  In fact,
in the current ext fs implementation, some space is still wasted because some
directory entries can use more space than needed when an unused directory entry
is reallocated (thanks to Wayne Davison for noting this).  In the next version
of the ext fs which will be "incompatible but upgradeable" and will be available
RRSN (really real soon now), this is corrected.

    Note that the limitation to 255 character is not really needed: with
1k blocks, we could limit the file names to 1012 characters (the header of a
directory entry is 8 bytes long) but I think that 255 is quite enough.


>--
>                                    +      Jim Winstead Jr. (CSci '95)
>                                    |      Harvey Mudd College, WIBSTR
>                                    |   [e-mail]
>                                    + or [e-mail]


--

    Remy Card
    [e-mail]