Date: Sun, 30 Jul 1995 09:27:56 +1000 From: Bruce Evans <bde@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. Message-ID: <199507292327.JAA16572@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507292327.JAA16572>