Am Sonntag den, 31. M=E4rz 2002, um 02:18, schrieb John Nemeth:

> On Jul 16, 12:28pm, Greywolf wrote:
> }
> } Um, something I just noticed.  HFS+ filesystems.
> }
> } I haven't played with it much in a LONG time, but the last time I =
did
> } anything with an HFS filesystem, the '/' character was valid in a
> } filename.  How did we work around this?
>
>      I worked on a system once that had some disks NFS exported to a
> Mac.  The Mac created a file with a '/' in the name.  That was fun.
> NOT!  No 'fsdb' either...  That would have made cleaning up the file
> too simple.
>
>      On the flip side, Macs use a ':' for a directory seperator
> character which, of course, is a perfectly valid character to put in a
> filename on a UNIX system.  Of course, this means that we could just
> substitute a ':' for any '/'s in the filename.

The way that I've seen is a mapping of special characters, one way or
the other. So the Mac side sees '/' but the unix side sees %100 (or=20
whatever..)

Also to note, HFS/HFS+ record case, but is not case sensitive, hence
one can not archive the NetBSD cvs source hierarchy on an HFS volume,
last time I checked there were about 200 files which differed only by=20
case.

find . -print |  tr "[:upper:]" "[:lower:]" | sort >/tmp/list
find . -print | tr "[:upper:]" "[:lower:]" | sort | uniq >/tmp/uniqlist
diff list uniqlist

if there are no files differing only by case, the diff should produce no
differences...

MS systems have the same case recording but otherwise insensitive
attribute as well...