Bug in A/UX 2.0.1

[Richard Todd]

sysmark at aurora.physics.utoronto.ca (Mark Bartelt) writes:
>Are you saying that, despite the fact that Mac files have file types
>associated with them, the finder nonetheless uses the *name* of the
>file to decide whether something is a driver or not?  If so, isn't

Actually, I believe it's the low-level file-handling code in MacOS, so
*every* MacOS app gets hit by it, not the finder.

>this a horrible botch even in the MacOS world?  And regardless, it's

It *is* a horrible botch, IMHO.  They shoulda gone the Unix approach and had
device special files.  Alas, it's 7 years too late to fix this...

>totally unacceptable in an A/UX environment, given the preponderance
>of files whose names begin with '.' under UNIX.

Rather annoying, yes.  A/UX does make some attempt to get around this; if
you notice on a Finder display of ones home directory under A/UX, one will
see the usual .-files (except for "." and "..") with the "." changed to the
"big-dot" character in the extended char set used by MacOS.  Alas, the
translation isn't implemented the other way.  It may not be *possible* to
do it the other way cleanly, as there's probably entirely too much code,
inside MacOS and out, that *depends* on being able to open those drivers.  

>Is something terribly wrong with A/UX in this regard, or have I just
>missed a joke that floated over my head?

The basic problem is one common to lots of environments, namely mapping one 
filesystem with one set of restrictions on name content/format to another.
The same sort of thing happens with people running MS-DOS and mounting NFS
filesystems from Unix hosts, or running VP/ix or similar MS-DOS emulation 
packages under Unix.  No matter what algorithm you choose for mapping 
filenames from one FS to another, somebody's going to get screwed by it. 
--
Richard Todd	rmtodd at uokmax.ecn.uoknor.edu  rmtodd at chinet.chi.il.us
	rmtodd at servalan.uucp
"Elvis has left Bettendorf!"