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.