Subject: Re: while we're looking at old bugs
To: None <current-users@NetBSD.ORG>
From: Christoph Badura <>
List: current-users
Date: 10/04/1997 18:01:24 (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

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)

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