On Thu, 2 Oct 1997, John F. Woods wrote:

> The last time I read the mv manual page, it was more than happy to accept,
> as arguments, the name of an existing file and the name of an existing
> directory, in that order.  For the case in question, it sure looks to me
> like the arguments (a file, and a directory on another disk) are perfectly
> *valid*.

Sure.  The problem here is that a rename(2) accross filesystems is
meaningless.  As a convenience, we fake this operation in the case of
source and destination files on different filesystems.  Unfortunately,
we cannot completely fake it in all cases unless we are root because of
_POSIX_RESTRICTED_CHOWN (bsd chown(2) semantics).  In this case, it is
open whether we should do only what we can silently, do only what we can
noisily, or fail outright.  NetBSD chooses the second.

> READ THE MANUAL PAGE.  I *defy* you to justify ANY ERROR MESSAGE WHATSOEVER
> simply because the file which is the source is not owned by the user running
> "mv".
> 
> QUITE TO THE CONTRARY, I claim that the manual page states that absolutely
> no message is permitted, because the mv(1) manual page explicitly defers to
> the cp(1) manual page, which explicitly says that no message is displayed.

The man page is wrong here.  Note that it also states that mv(1)
actually calls cp(1) and rm(1) to do its work in this case, which is
only the case for directories.

I agree that the mv(1) implementation is wrong in having different
semantics in this case for files and directories.  I think this should
be changed.  It is _not_ clear that it should be changed to require
cp(1) and rm(1) be forked for plain files -- I would argue that on the
contrary, fts(3) should be used for directories...

> I repeat, I defy you to justify printing an error message based on the
> documented behavior.  If you choose to claim that the documentation is wrong,
> I then ask you to justify breaking shell scripts that have been around longer
> than NetBSD has.

Well, plenty of old shell scripts are already broken by BSD's restricted
chown(2) behavior.  Nonetheless, this behavior is not only standardized,
but desirable.

At any rate, the ability to mv(1) to a directory on another filesystem
is itself _new_.  4.3 did not allow this.  SVR2 did not allow this.  4.4
added this.  If the scripts are new enough to expect this, they're
surely new enough to expect restricted chown.  Or they are in error...

--
				Jim Wise
				jim.wise@turner.com