On Tue, Apr 10, 2001 at 02:55:43PM -0400, Jarvis, Robert P. (Contingent) wrote:
> > "mv" tries to behave transparently in both cases because in UNIX, file
> > systems can be mounted anywhere, transparent to the user.  In Windows
> > and MacOS this is less of an issue because the OS makes it painfully
> > obvious when your data resides on different file systems.
> 
> Under NT, and perhaps under other Win variants as well, the "move" command
> will move and rename files across directories, disks, and machines.

Yes, but it won't move directory trees.

> IMHO Squeak should behave consistently across platforms.

I agree.  I would add that I think the primitives should not have
behaviors that are difficult to predict, so I think a single file
copy or copy of a directory tree should only happen if the program
calls an appropriate API.

UNIX puts together "rename", "move", etc. into a single call at the OS
level because it can implement them all pretty much equally efficiently.
I believe FAT cannot (or didn't use to be able to) move directories
around without actually copying them.  The distinction Windows made
was because of limitations of the file system.

I think with NT/XP/2K and MacOS X, all systems are now pretty much like
UNIX now in this regard: moving files and directories around within
the same file system is no worse than just renaming them within the
same directory.  So, I think the primitives I would like to see are:

    "move a file or directory tree around within a single file system, 
    including renaming, but fail clearly and predictably if this can't 
    be done"

    "copy a file or directory tree"

    "delete a file or directory tree"

    "move a file or directory tree by copying then deleting individual files"

At the UI level, however, I think it is better to have consistent behavior:
either copy by default or ask by default.  Windows tries to do different
things depending on where things are coming from and going to, and while
that may be convenient most of the time, I think it invites errors.

Tom