From: Marko Mäkelä (marko.makela_at_hut.fi)
Date: 2005-05-11 13:21:26
On Wed, May 11, 2005 at 12:57:19PM +0200, Patrycjusz R. £ogiewa wrote: > > (Oh well, newer file > >systems have problems with file names as well. Take the > >case-insensitive > >Apple HFS+, for example. If I have understood the technical notes > >correctly, > >the case-folding will effectively treat strings consisting of non-Latin > >letters as empty strings. This would mean that e.g., Greek, Russian or > >Japanese users would have to give Latin names to their documents.) > > Disagreed. > > This kind of case-insensitivity as used in HFS+ has its own name, which > I forgot but it certainly doesn't affect using non-Latin filenames. I was referring to this technical note: http://developer.apple.com/technotes/tn/tn1150.html It seems that I confused HFS+ with HFS: "The problem with using non-Roman scripts in an HFS file name is that HFS compares file names in a case- insensitive fashion. The case-insensitive comparison algorithm assume a MacRoman encoding. When presented with non-Roman text, this algorithm fails in strange ways. The upshot is that HFS decides that certain non-Roman file names are duplicates of other file names, even though they are not duplicates in the source encoding." Anyway, I think that it is a bad idea to disallow a large group of characters or strings in a file system. Unix-like file systems do it nicely: the only disallowed characters are the directory separator and NUL, the end-of-string marker in C library routines. Well, Commodore takes this further, treating the file name as an arbitrary binary string. Marko Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.