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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 10 May 2007 12:14:46 -0400 (EDT)
From:	"John Anthony Kazos Jr." <jakj@...-k-j.com>
To:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
cc:	Bodo Eggert <7eggert@....de>, Albert Cahalan <acahalan@...il.com>,
	Andrey Borzenkov <arvidjaar@...l.ru>,
	hirofumi@...l.parknet.co.jp, linux-kernel@...r.kernel.org,
	hpa@...or.com
Subject: Re: Long file names in VFAT broken with iocharset=utf8

> >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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/