[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] MiNT-Net configuration files
- To: MiNT List <mint@fishpool.com>
- Subject: Re: [MiNT] MiNT-Net configuration files
- From: Michael Schwingen <rincewind@discworld.dascon.de>
- Date: Sun, 10 Oct 1999 22:59:00 +0200
- In-reply-to: <Pine.MNT.4.10.9910081645200.108-100000@rakastaja>; from Martin-Eric Racine on Fri, Oct 08, 1999 at 04:51:47PM +0300
- Mail-followup-to: MiNT List <mint@fishpool.com>
- References: <Pine.MNT.4.10.9910081527260.128-100000@milan> <Pine.MNT.4.10.9910081645200.108-100000@rakastaja>
- Sender: owner-mint@fishpool.com
On Fri, Oct 08, 1999 at 04:51:47PM +0300, Martin-Eric Racine wrote:
>
> Speaking of this, it seems both Thing and the GNU utils have
> problems with filenames longer than 32 characters. "Dir" works,
> but "rm" and "mv" (among others) refuse to see any files with
> longer names and auto-expansion in both Bash and Tcsh fails.
> This happens on Minix and Ext2 filesystems.
Right, I noticed this one, too (and yes, this really happens in daily use
when downloading files like
GimpUserManual-1.0.0-html.tar.bz2
netbsd-current-sys-19990702.tar.gz
> Btw, I seem to recall that our libs have a function to determin
> the maxium filename lenght? As VFAT allows up to 64 characters
> and Minix 62 (in the default setting), could we standardize on
> 62 as our default, in general (unelss anybody can think of some
> other lenght that would be more appropriate)?
If there are filesystems supporting 64 (and I am quite sure ext2 can do even
more), then 62 is obviously a bad choice, since it may make files with
longer names unaccessible, so a reasonable default should be 'big enough'
for *all* filesystems.
If programs need more detail, there are functions to find out the limits on
a special filesystem (and IIRC, the kernel may report 'unlimited').
cu
Michael
--
Michael Schwingen, Ahornstrasse 36, 52074 Aachen