NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/os/linux/25647

Text File | 1993-01-28 | 2.8 KB | 48 lines

Newsgroups: comp.os.linux
Path: sparky!uunet!enterpoop.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!dmuir
From: [e-mail] (Douglas Muir)
Subject: Re: Filesystems for people providing packets
Message-ID: <[e-mail]>
Sender: [e-mail] (News system)
Nntp-Posting-Host: carbonara.mit.edu
Organization: Massachusetts Institute of Technology
References: <[e-mail]> <[e-mail]>
Date: Wed, 27 Jan 1993 23:47:42 GMT
Lines: 35

With regard to people who provide packages using a filesystem which supports
long file names, I would like to point out that this really only applies to
those who are porting packages which already use long file names.  One example
is gwm (not to malign the person who ported this package, I'm sure everyone
who uses the package is glad he did).  The main program in this package (gwm)
and its support files were all written to use long file names, and the support
files include other support files with long file names, etc.  On a minix
filesystem, with truncated names, all works well - the filenames are shorter
and the filesystem, knowing this, will open the file xxx-yyy-zzz-ww even
though the name of the file actually requested was xxx-yyy-zzz-www.  However,
the problem arrises when the porter with the minix filesystem tars up the
package and uploads it for others to use.  If the user happens to have a
minix filesystem, everything works - the package (all of whose filenames are
now max 14 chars - regardless of what they were originally) untars fine - no
filenames get truncated since the truncated filenames are what are in the
archive - and the user runs the program without trouble, because even though
the program is still looking for file xxx-yyy-zzz-www, his filesystem is
opening xxx-yyy-zzz-ww.  But when someone with an extended filesystem (and by
extended I mean any of the fileystems which have long filenames) untars the
package - he gets the files with the truncated names on his disk.  When he
goes to run the program, the package tries to open file xxx-yyy-zzz-www, but
there is no such file.  The user has to rename the file xxx-yyy-zzz-ww.  The
only reason I'm explaining this (which really is pretty obvious - once you
stop to think about it) is that many people apparently don't think about it,
as evidenced by the rather harsh response the original poster received.  So
there are good reasons why package maintainers should attempt to preserve
the "longness" of filenames in their packages - though I do recognize that the
people who maintain and distribute these packages do so on a volunteer basis
only, and as such, we really have no right to complain about anything they
do.  If the only price I have to pay for the convenience of having a
pre-compiled package is a little bit of time spent renaming files, that's
fine with me.
                            -Doug Muir