From owner-freebsd-bugs  Tue Jul  9 16:09:10 1996
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id QAA16660
          for bugs-outgoing; Tue, 9 Jul 1996 16:09:10 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA16654
          for <freebsd-bugs@freefall.freebsd.org>; Tue, 9 Jul 1996 16:09:05 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id JAA09150; Wed, 10 Jul 1996 09:03:05 +1000
Date: Wed, 10 Jul 1996 09:03:05 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199607092303.JAA09150@godzilla.zeta.org.au>
To: bde@zeta.org.au, zach@blizzard.gaffaneys.com
Subject: Re: bin/1375: Extraneous warning from mv(1)
Cc: freebsd-bugs@freefall.freebsd.org
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>>  This is probably a bug in mv.1.  mv should and does try harder than
>>  cp to preserve attributes.

>But why should I, as a user, care.. as long as the setuid/setgid bits

Some users might care.  E.g., if the file is supposed to have a particular
gid so that everyone in the group can access it, then mv'ing it across
file systems will break group accessibility even if you put it back.  Try
this:

	touch /tmp/z		# gid is same as /tmp (bin)
	mv /tmp/z ~		# gid gets clobbered to your gid
	mv ~/z /tmp		# gid is still yours, not bin

mv cannot know if the user cares, so it shouldn't silently drop
attributes.  I now think it should refuse to the move if it can't
preserve all the attributes.  It can simply unlink the target and
avoid unlinking the source if there is a problem.

The problem is much more complicated for moving entire trees.  Is
mv supposed to successfully move the entire tree before unlinking
anything in the original tree and then check that all unlinks would
succeed before unlinking anything?  I think it should.  Otherwise an
error leaves both the source and target trees in a mess.  Try this:

	mkdir /tmp/z mkdir /tmp/z/a
	touch /tmp/z/b /tmp/z/c /tmp/z/a/d /tmp/z/a/e
	su
	chown root /tmp/z/a /tmp/z/c /tmp/z/a/e
	exit
	mv /tmp/z ~

This gives suitable error messages for not being able to move /tmp/z/a
or its contents.  It silently moves /tmp/z/c and loses its uid.  The
target tree ends up with all the files from the source tree (everything
is readable so there is no problem copying it) and everything possible
got removed from the original tree because the `cp -pRP' step succeeded
although it didn't preserve one uid.  Messes like this are easy to
create using cp -pRP and rm -rf explicitly :-).  mv across file systems
is of negative worth unless it does a better job of makeing the move
atomic.

Bruce