Hi all,

Craig Hoyt <craig@...> is working toward an implementation of the
improved trash management system I have been trying to imagine. And he's
making good progress, initially on part (2). So let me extend the thread.

My approach is to imagine how the classical Mac trash management system
must be implemented by the Finder via the existing toolbox calls.

The closer we stay to that lifeline the more acceptable will be the result to
other mac users. 

The Wintel trash management I have seen is utter rubbish by comparison :)
Which reminds me of a sad story. A friend who is a physics institute Wintel
sysop has always been diligent in system and hard disk renewal. That means a
whole lot of copying and deleting.  One time, a bunch of valuable folders of
his on a disk he was *not* intending to alter unexpectedly **vanished**. On
examining the matter he figured that he had deleted folder aliases on the
disk to be renewed in such a way that his valuable folders on his precious
disk were killed, and not the aliases.  "Funny as a rubber crutch" I said.
"Yeah" he replied "one of the folders was our joint project"... :-/ The Mac
Toolbox, if misused in the present project, can do the same damage as in my
Wintel tale. But the Finder is rather more considerate. Our proposed
improvement has to be just as considerate as the Finder, or moreso!

My last version of the design was in two parts (1) and (2#):

 > (1) On every volume (directory?) on which trash has potential 'hidden'
 > value, create a folder called 'JunkYard_<Volume name>' or
 > 'RecyclingBin_<Volume name>'; give it a characteristic custom icon; and
 > place an alias to it on the desktop.

There is more to add to (1):-

The creation of such recycling bins should be the job of a (normally unique)
trash management program.  To create the bin in a given folder, the user
would drag and drop the folder icon onto the manager's icon. (Best just one
bin per volume? Well at least just one per folder.)  To avoid some dreadful
mishaps, recycling bins have to be clearly identifiable as such, say via the
custom icon I mentioned, and demo'd at

    ftp://topo.math.u-psud.fr/pub/lcs/fb/WasteMgr_try.cpt.hqx

Some users might like to forbid dropping anything but a root directory, ie a
volume; that might be a configuration option.



 > (2#) Create an application with FB called something like "Incinerate",
 > and place it in the recycling bin folder of (1); a suitably named alias
 > to it can be placed on the desktop. This incinerator application should
 > behave as follows: When this incinerator application is launched, the
 > contents of the containing folder are deleted -- after a suitable
 > warning about what is to be deleted and about the finality of this
 > deletion. As a safety measure, aliases therein should, by default, be
 > themselves deleted and not the objects aliased -- just as in the
 > Finder's own trash system.

There is more to add to (2#):-

(a) It seems wise to forbid the deletion operation or at least give special
warning if the folder is not recognizable as a recycling bin.

(b) Never delete busy or invisible files/folders unless the option key is held down
and maybe not even then, cf. Finder policy.



There is also an alternative (2##) to (2#) that is really a revival of my
original (2):-

(2##)  In this scheme the incinerator application behaves as follows when a
'Recycling Bin' is dropped on its icon.  It checks that the directory is
indeed a recycling bin, and if so offers to delete its contents, commenting
that any alias will be deleted and not the object that the alias points to.

Dropping files, and dropping more than one object should both be forbidden in
the interests of clarity -- and lead to gentle scolding. There's also an
efficiency consideration here. You may recall that the up-to-date Apple Event
style of D&D is extremely slow (a couple of seconds of overhead or more per
item dropped), and, for directories, it is the only D&D mechanism available.
For a single directory the overhead is tolerable.  Directory scanning (eg for
killing) is greased lightening by comparison. Incidentally does OS9.2 have a
high level call for directory destruction with enough options to be of use
here??

Note that points (a) and (b) apply to (2##) as well as to (2#).

Analogy with the Finder's's trash management system suggests that the
incinerator app *not* destroy the recycling bins.  To destroy them use the 
Finder!


Notice that the 'Incinerator' application mentioned in (2##) can be one and
the same application as the trash management program mentioned for (1). I
would suggest that, when a directory is dropped on it, which is not a
'Recycling Bin', the result be as follows:-

 -- if there is one or more 'Recycling Bin' at the top level of the 
directory, then that is announced and the user is invited to exit.

 -- if there is no 'Recycling Bin's at the top level of the 
directory, then there is an offer to create one.

An appropriate name for the double-duty 'trash manager and incinerator'
might be "Dustman" or "Janitor".  The whole improved trash
management system is then a single application of moderate size.

I guess it is clear that today I prefer this "Dustman" or "Janitor" design
involving (1) and (2##).  It seems a pretty civilized descendent of the 
'Serial Killer' application I first posted.

Comments/improvements/caveats invited!

Cheers

Laurent S.