🚀 go-pugleaf

>   So tell us:  what's the gain from the proposed change?

I think -- though this is just a guess on my part -- that the finder change
may be intended to cover up a flaw in the current filesystem.

Presently the Macintosh filesystem is extremely primitive.  It's primitive
compared to Unix; it's primitive compared to the Macintosh user interface.
The folders do not implement a true hierarchical filesystem because the
folders are not directories, they are essentially just name-modifiers which
serve to cluster groups of files together (and on top of which an image of
a file folder has been built) within a flat namespace.

There appears to be a problem with the folder implementation besides the
fact that they don't make the directory system heirarchical: when you move
a file onto the desktop, the identity of the folder it came from is
apparently lost.  When you use the (soon to disappear) "put back" feature
from the desktop, the file does NOT go back to the folder it came from, it
goes only back into the disk window of the disk it came from. (At least,
this is the case with the 1.1g finder I am using.)

It's been awhile since I had access to an Inside Macintosh, and I don't have
the $25 one yet, so someone else will have to verify whether this is indeed
a problem, and what the cause of it is.  I vaguely recall that there is an
integer field that identifies which folder a file is in, but I can't recall
why one of the finder flag bits couldn't be used to indicate "currently
on the desktop".  In fact, it's not clear to me why the files don't go back
to their proper folders NOW when a "put back" is done.

I can see how some problems could exist with "put back" -- i.e., when is
a file only temporarily in a folder, vs. when is it permanently put there;
yet this could be solved by having "clean up" make folder assignments
permanent, with movements being temporary until then.

But somehow I suspect that the current "improvements" are intended to
circumvent flaws that it would be harder to fix than have disappear.  I'm
not sure this is a good idea, although I can see how difficult it would be
at this late stage to completely rework the filesystem, given the need for
compatibility with previous versions.
-- 
Full-Name:  J. Eric Roskos
UUCP:       ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer
US Mail:    MS 795; Perkin-Elmer SDC;
	    2486 Sand Lake Road, Orlando, FL 32809-7642