Tim Rowledge <tim at sumeru.stanford.edu> wrote:
	Sure, it's not hard to do in image code, but it is likely to be much,
	much slower than a library call to delete the directory.

What library call is that?
In UNIX, rmdir() requires the directory to be empty.
In Windows, RemoveDirectory() requires the directory to be empty.
In MacOS, is FSDeleteContainerLevel() now regarded as a standard
   function?

The fundamental problem with recursively deleting a directory and its
contents is that in a multi-user system you very often CAN'T.  If you
do 'rm -rf SomeDir', and IF you own all the files and directories
therein, then SomeDir and its descendants will vanish.  But IF there
is one file that you don't own, that file and the directories on the
way to it will remain.  In some versions of UNIX, you can't delete an
executable file if some instance of it is still running; I expect the
same is true of .so files although I've never tried it.

What I would REALLY REALLY like is something that either
 - tells me about all the files that are going to get in the way
   AND DELETES NOTHING, or
 - having found that there will be no problem, goes ahead
   and deletes everything.

Yes, this requires a two-pass algorithm, and I've never implemented it
because I don't know how to check whether an a.out or .so is in use.
(One obvious method is to try to append a NUL byte and then truncate
it off again, but that's not going to work if the file is write-protected.)
But if it was easy, it might as well be done in Smalltalk.  The time
argument isn't impressive because most of the 'calendar' time is likely
to be spent touching the disc.