[missing-sync-palmos-talk] Re: Extraordinarily bad Missing Sync bug

[Dave Butenhof]

> I tried to file a bug report on the site, but here's the result I  
> got from
> the support team:
>
> This is not a bug in the Missing Sync. It is an improper naming  
> convention
> to use on a computer that is based on a Unix operating system. I  
> suggest
> that you do not use non-ASCII characters in filenames or folders.
>
> The "/" character is not allowed in filenames or folders in Mac OS.  
> You
> would have similar problems if you started the filemane or folder  
> with "."
> or " " (a space). If the filenames or folders were deleted, there  
> is no
> place I can point you to to recover them.
>
>
> So basically it was all my fault and the support team seems to  
> think that
> Missing Sync deleting files is in fact normal behaviour. Plus they  
> don't
> know what filenames are legal in the Finder. Do they hire Linux  
> guys for the
> support team?

Legal file names in Mac OS X are complicated by several layers.  
Basically, HFS+ is running on top of a UNIX filesystem.

In HFS+, ":" is the directory separator, and can't be used in filenames.

In UNIX, "/" is the directory separator, and can't be used in filenames.

In the Finder, on a typical Mac OS X system running HFS+ on top of  
UNIX, both are true, in a sense.

If you create a file "foo:bar" in the Finder, it'll tell you that you  
can't do that -- it's not an HFS+ filename. But since "foo/bar" is a  
legal HFS+ filename, and might exist on an old Mac OS 9 HFS+ disk,  
it's allowed. But to UNIX it's really "foo:bar", because THAT'S  
legal, while "foo/bar" isn't. (Try it: create "foo/bar" in your  
~username home directory, open a Terminal window, and type "ls";  
you'll see "foo:bar". You can do it the other way, too, of course:  
"touch foo:bar" to create a file, then look at your Finder window.)

So the problem is a matter of viewpoint. Programs using UNIX APIs  
will see "foo:bar" while HFS+ APIs will see "foo/bar", but they're  
the same file. It's not hard to imagine cases where this could be  
really confusing, and the advice to avoid both where practical makes  
a good deal of sense.

Of course since "/" is a "native filename character" on the default  
HFS+ Mac OS X filesystem, any Mac OS X utility ought to support it;  
whether through HFS+ APIs as "/" or through UNIX APIs as the ":" to  
which it will be mapped. And wiping out user data is never acceptable  
-- especially when BOTH filenames are perfectly legal, each in the  
proper API domain. (A bug like this is perfectly understandable; but  
deserves an apology and a fix, not "it's your problem".)