Subject: Re: while we're looking at old bugs
To: None <current-users@NetBSD.ORG>
From: Christoph Badura <firstname.lastname@example.org>
Date: 10/04/1997 18:01:24
email@example.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
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.
Now available in print: Lion's Commentary on UNIX 6th Edition, with Source Code