From owner-freebsd-hackers  Sat Jul 29 16:32:54 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id QAA04653
          for hackers-outgoing; Sat, 29 Jul 1995 16:32:54 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id QAA04644
          ; Sat, 29 Jul 1995 16:32:46 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id JAA16572; Sun, 30 Jul 1995 09:27:56 +1000
Date: Sun, 30 Jul 1995 09:27:56 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199507292327.JAA16572@godzilla.zeta.org.au>
To: freebsd-bugs@FreeBSD.org, freebsd-hackers@FreeBSD.org,
        ponds!rivers@dg-rtp.dg.com, ponds!rivers@zeta.org.au,
        zeta.org.au!bde@dg-rtp.dg.com
Subject: Re: Problem with /bin/mv on 2.0.5.
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

>  1) The owner of all the files/directories is 'user'; there group id
>	of all the files/directories is the same, and is 'user'.

/tmp has group bin unless you've changed the default.

>  2) This operated "correctly" at 1.1.5 and 2.0 - that is, no message
> 	was generated when the 'mv' occured.

>  3) The source for 'mv' hasn't changed from 2.0 to 2.0.5; so I don't
>	think that would be a fruitful place to look.

>  4) /tmp is a different file system from /usr, and I have always done
>	that (that is, in my 2.0 system, /tmp was a different file system.)

Perhaps /tmp had the wrong group in 2.0.

> I think the problem is the fchown() is being more aggressive at checking
>in 2.0.5 than it did at 2.0 - possible more so than is correct.

No.  It was more agressive in 2.0.  It is correct for it to report changes
that can't be made as errors.

Perhaps mv should be quieter about such changes.  I think it should
report uid and mode changes but not gid changes for the case here
(moving by non-root from a sticky public dir) where it is known that
preserving the gid is impossible.  The uid may be lost for moves from a
non-sticky public dir.  The mode may be lost for moves of sticky dirs
(e.g., by cp and mv fail to preserve the sticky bit when /tmp is `cp
-pR'ed.  This bug would have been more obvious if the mode was checked).

Bruce