From owner-freebsd-bugs Fri Jul 28 20:23:22 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id UAA20885 for bugs-outgoing; Fri, 28 Jul 1995 20:23:22 -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 UAA20853 ; Fri, 28 Jul 1995 20:22:57 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id NAA14124; Sat, 29 Jul 1995 13:19:59 +1000 Date: Sat, 29 Jul 1995 13:19:59 +1000 From: Bruce Evans Message-Id: <199507290319.NAA14124@godzilla.zeta.org.au> To: freebsd-bugs@FreeBSD.org, freebsd-hackers@FreeBSD.org, ponds!rivers@dg-rtp.dg.com Subject: Re: Problem with /bin/mv on 2.0.5. Sender: bugs-owner@FreeBSD.org Precedence: bulk >If you have the following directory: > /usr/user/DIR >and the mode of DIR is as in: >drwx------ 2 user general 512 Jul 28 20:34 DIR/ >and you execute the following (as the user 'user'): > cd /tmp > touch t > mv t /usr/user/DIR >you will get a message from mv: > mv: /usr/user/DIR/t: set owner/group: Operation not permitted When a file is moved across file systems, it is impossible to preserve the group if the user is not a member of the original group. >the message was not produced at 2.0. I have determined that /bin/mv >hasn't changed, and that this message is produced by /bin/mv when >the fchown() call for the destination failed, with errno set to EPERM. > So, what's changed in fchown() that would cause this - the message >is quite aggravating. fchown() was changed to reduce the problem. Now it is not an error to fchown() a file to the same owner/group that it already has. Previously this was an error if the user didn't belong to the target group. Now it is possible to move a file across file systems without getting the error provided the target directory has the same gid as the source file, but there is no difference for the more common case of a file in /tmp that has a different gid to your home directory. You probably had your user directory on the same file system as /tmp in 2.0. mv was too broken to report the error in 1.1.5. Bruce