On Sun, Feb 10, 2002 at 08:48:36PM +0200, Ilya Konstantinov wrote: > > Before Linux FTP daemons could offer filenames in a definite encoding, > Linux needs some way to get a definite of a filename, and AFAIK the > kernel offers no such standard way (via an extended version of readdir > etc.). Moreover, ext2 doesn't even define a standard encoding for > filenames (unlike NTFS filesystems, which define Unicode as the internal > filename storage form, removing the encoding ambiguity). > > Are there any functions for this on other Unixes? (I guess such > functions weren't defined by POSIX) Or will Linux / glibc need to make > up its own function names for this functionality? (if we'd ever apply > with this problem to the Linux kernel maintainers and they'd agree to > fix it)
UNIX treats all user data as opaque in principle, so explicitly admitting that file names may have different encodings in an API would be very ugly (but see the newly-accepted "extended attributes" API in 2.5.x). I cannot see any benefit in having a single filesystem allow different files to have different encodings for their names, so the only issue is encoding conversion done in each filesystem's code between the on-disk representation and some standard Linux encoding (UTF8?). I assume that such conversion is done because Linux can be configured to support certain Windows charset codepages explicitly. So this is a pure userspace issue -- if all the files you create on your system are named with a standard encoding then there's no problem for an FTP server to convert to it any encoding the client requests. And if you /don't/ create all the files on your system with the same encoding, no kernel feature can help you. ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
