> mv(1) should not require a directory-based adbod to be automagically
> tarred and untarred.
> Now, I realise that some people may say that mv(1) won't move
> directories across filesystems. True. We should fix mv(1) to
> effectively do <cp -a; rm -rf> (with error checking).
> Don't be confused by thinking mv(1) is an interface to rename(2),
> because it isn't. mv(1) can move files across filesystems, and file
> and directories within a filesystem. So mv(1) is lacking in symmetry.
> Let's fix that.
There is no such asymmetry, at least not in theory.
POSIX.2 states that mv will move directories as well as files,
also across filesystems.
>From mv(1):
DESCRIPTION
mv moves or renames files or directories.
...
When both source and destination are on the same filesys
tem, they are the same file (just the name is changed;
owner, mode, timestamps remain unchanged). When they are
on different filesystems, the source file is copied and
then deleted. mv will copy modification time, access
time, user and group ID, and mode if possible. When copy
ing user and/or group ID fails, the setuid and setgid bits
are cleared in the copy.
GNU DETAILS
The GNU implementation (in fileutils-3.16) is broken in
the sense that mv can move only regular files across
filesystems.
Ragnar Hojland Esp writes:
> Depends on mv. A posix compilant mv(1) won't, but a GNU
> fileutils >= 4.0 will.
but as mentioned this is incorrect. A POSIX compliant mv(1)
will move directories, but GNU fileutils 3.16 is not POSIX
compliant. Apparently GNU fileutils 4.0 corrects this - I have
not yet seen it. Updates for the man pages are welcome.
Albert D. Cahalan writes:
[speculations deleted]
Andries - aeb@cwi.nl
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/