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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 9 May 2007 19:57:06 +0400
From:	Andrey Borzenkov <arvidjaar@...l.ru>
To:	"Albert Cahalan" <acahalan@...il.com>
Cc:	"Jan Engelhardt" <jengelh@...ux01.gwdg.de>,
	hirofumi@...l.parknet.co.jp, linux-kernel@...r.kernel.org,
	hpa@...or.com
Subject: Re: Long file names in VFAT broken with iocharset=utf8

On Wednesday 09 May 2007, Albert Cahalan wrote:
> On 5/8/07, Jan Engelhardt <jengelh@...ux01.gwdg.de> wrote:
> > On May 8 2007 00:43, Albert Cahalan wrote:
> > > Fix: the vfat driver should use the 8.3 name for such files.
> >
> > Or the 31-character ISO Level 1(?).
>
> That might be appropriate for a similar problem on CD-ROM
> filesystems. (when the CD is rockridge KOI8 and you want UTF-8)
> It may even be appropriate for Joliet, though 8.3 may be
> the better choice in that case.
>
> It's not appropriate for vfat, HPFS, JFS, or NTFS. All of those
> have built-in support for 8.3 aliases. Normally the 8.3 names
> are like hidden hard links, except that deletion of either name
> will wipe out the other. (same as case differences too)
> So the names are there, and they should already work.
> They just need to be reported for directory listings when the
> long names would be too long.

several problems associated with it

1. those names are rather meaningless. How do you find out which file they 
refer to? It is OK for trivial cases but not in a directory full of long 
names; nor am I sure how many unique short names can be generated.

2. directory contents is effectively invalidated upon backup and restore (tar 
c; rm -rf; tar x). It is impossible to infer long names from short ones.

3. this still does not answer how can I *create* long name from within Linux.

Currently workaround is to mount with single byte character set, like koi8-r; 
of course it becomes quite awkward if the rest of system is using UTF-8.

Content of type "application/pgp-signature" skipped