jimw@numenor.turner.com (Jim Wise) writes:

>As several people have pointed out, mv(1) traditionally failed to rename
>_directories_ across filesystems, but would invoke cp(1) followed by
>rm(1) for individual files.

>The intent of invoking cp(1) followed by rm(1) was to maintain the
>semantics of a rename, modulo the fact that hard links cannot span
>filesystems.

This is still incorrect.  mv(1) had had this behaviour years before
rename(2) was introduced into BSD.

>The introduction of _POSIX_RESTRICTED_CHOWN added another
>point in which rename semantics could not be exactly preserved.  At that
>time, the choice was made to report to the user if the call to fchown(2)
>failed.

It was?  Then how come that SunOS 4's mv(1) doesn't emit that bogus warning?


>Given that we can assume _POSIX_RESTRICTED_CHOWN, should we be
>trying this call to fchown(2)?  i.e., should NetBSD mv(1) have different
>semantics in superuser state?

Good question.  At least on SunOS 4 it doesn't try to preserver owner
and group if invoked by root.
-- 
Christoph Badura

Now available in print: Lion's Commentary on UNIX 6th Edition, with Source Code
			http://www.peer-to-peer.com/