Harald Alvestrand <[EMAIL PROTECTED]>:
> >1. Introduce an as yet undesigned but probably complex and insecure
> >system by which file names are automatically converted to the
> >appropriate encoding.
>
> note: this is ALREADY IMPLEMENTED IN LINUX for the FAT filesystem.
> see kernel docs - Documentation/Configure.help, under "NLS".
>
> If it has to be done - it has to be done in the kernel, at filesystem level.
Do you know of any more information about how this works?
I think there are two separate things here:
1. How programs talk to the kernel (or the C library). This is what I
was talking about, and I suggest that at this interface file names
should be just null-terminated octet-sequences.
2. How the kernel talks to a file system. This is what you are talking
about, and you are right that file name translation is necessary where
the file system may be shared between different systems (on a network
or removable media).
An illustration of them being separate might be if a file system with
UCS-2 names is exported over a network to a system that mounts it as
ISO-8859-1. Then a particular user of that system might nevertheless
decide to use UTF-8 file names, which would then seem to be full of
strange Ä?-digraphs for anyone who looks at them in UCS-2 on the host
system.
I would like to understand better what happens when file name
conversion is not possible. What guarantees, if any, are made by which
standards about what might happen to file names in this case? For
example, might a file you create have a different name from what you
asked for? Might several files in the same directory appear to have
the same name? What errnos do you get from open()?
Edmund
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
