Re: Long file names in VFAT broken with iocharset=utf8

John Anthony Kazos Jr.
2007-05-10T16:15:21Z

> >Just because you limit yourself to 80 chars minus "ls -l"-clutter, this is
> >no reason why I shouldn't use long filenames. If I need to handle these
> >filenames, I can enlarge the terminal window or read the next line.
> >
> >E.g.: I have a music file named "artist - title.ext", where the artist
> >name is 103 characters long, using abbreviations. In order to enter that
> >name, I have to press seven keys, including the escape character.
> >There is nothing unreasonable in using that name.
>
> What name would that be? I cannot dream up any IME that outputs _that_
> many characters for that few keystrokes. Even with CJ(K), 7 keystrokes can
> make at most 21 bytes if I had to take a good guess.

Probably talking about tab-completion in the shell, countering the comment
that names that long are too unwieldy to use.

On the other hand, limits are always bad. Haven't we seen bajillions of
cases in computing history where we start with limits (like only N of the
first characters of identifiers used in compilers), followed by people
finding those limits annoying, then followed by the limits being removed?
How about the Year-20?? limitations? Same thing: limits that were fine,
then limits were not fine, then limits were removed.

In this era, couldn't we just skip the whole thing and stop putting limits
in from the beginning? The only reason to have a PATH_MAX/NAME_MAX at all
is to make life easier for programmers implementing things and people
using things. It would require a LOT of work and changes, but life would
be so much better if there were a (configurable, of course!) option to say
"use standard values" or "use custom values" or "use runtime-dynamic
values". Option 1: No change. Option 2: Alter your limits.h too, and
recompile programs (or fix them). Option 3: Change programs from
compile-time inclusion of limits.h to run-time checking of a /sys value.