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

[Andrey Borzenkov <arvidjaar@mail.ru>]

[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]

On Wednesday 09 May 2007, Albert Cahalan wrote:
> On 5/8/07, Jan Engelhardt <jengelh@linux01.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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]