Re: Data transfer methods

From: Marko Mäkelä (
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:

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.


       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.