jkp@cs.HUT.FI (Jyrki Kuoppala) (08/25/89)
jkp@joker.hut.fi 'src' 451: ls -lagF total 4 drwxrwxr-x 4 root staff 512 Aug 25 01:04 ./ drwxr-xr-x 6 nobody wheel 512 Aug 23 23:33 ../ drwxr-xr-x 2 haa staff 512 Aug 24 16:32 OS-hd-fix/ drwxrwxr-x 4 jkp staff 512 Aug 25 01:04 local/ jkp@joker.hut.fi 'src' 452: jkp@joker.hut.fi 'src' 452: mv OS-hd-fix local mv: OS-hd-fix: rename: Permission denied jkp@joker.hut.fi 'src' 453: groups staff wheel operator jkp@joker.hut.fi 'src' 454: whoami jkp According to the documentation (rename(2) and mv(1)) there's no reason the `mv OS-hd-fix local' shouldn't work. This seems like a bug. Environment: 4.3 BSD (news-os 3.2 on a Sony NWS-1830; Mt. Xinu's bsd 4.3 on a uVax II; Sunos 4.0.1 on a Sun 4/260). //Jyrki
dik@cwi.nl (Dik T. Winter) (08/25/89)
In article <24612@santra.UUCP> jkp@cs.HUT.FI (Jyrki Kuoppala) writes: > jkp@joker.hut.fi 'src' 451: ls -lagF > total 4 > drwxrwxr-x 4 root staff 512 Aug 25 01:04 ./ > drwxr-xr-x 6 nobody wheel 512 Aug 23 23:33 ../ > drwxr-xr-x 2 haa staff 512 Aug 24 16:32 OS-hd-fix/ > drwxrwxr-x 4 jkp staff 512 Aug 25 01:04 local/ > jkp@joker.hut.fi 'src' 452: mv OS-hd-fix local > mv: OS-hd-fix: rename: Permission denied You will also get this error message if 'local' contains a non-empty directory 'OS-hd-fix' for which you do not have execute permission. And probably in other situations also. -- dik t. winter, cwi, amsterdam, nederland INTERNET : dik@cwi.nl BITNET/EARN: dik@mcvax
npl@cbnewsi.ATT.COM (nickolas.landsberg) (08/26/89)
In article <24612@santra.UUCP> jkp@cs.HUT.FI (Jyrki Kuoppala) writes: > jkp@joker.hut.fi 'src' 451: ls -lagF > total 4 > drwxrwxr-x 4 root staff 512 Aug 25 01:04 ./ > drwxr-xr-x 6 nobody wheel 512 Aug 23 23:33 ../ > drwxr-xr-x 2 haa staff 512 Aug 24 16:32 OS-hd-fix/ > drwxrwxr-x 4 jkp staff 512 Aug 25 01:04 local/ > jkp@joker.hut.fi 'src' 452: mv OS-hd-fix local > mv: OS-hd-fix: rename: Permission denied "mv" only allows the rename of a directory "only if the the two directories have the same parent." In this case, the attempted move was to a different directory. Details of why whis is have slipped from memory but probably have somthing to do with the necessity of changing the inode number for ".." in the original directory in addition to changing link counts in the original parent and the new parent. Nick Landsberg
deastman@pilot.njin.net (don eastman) (08/26/89)
In article <647@cbnewsi.ATT.COM>, npl@cbnewsi.ATT.COM (nickolas.landsberg) writes: > In article <24612@santra.UUCP> jkp@cs.HUT.FI (Jyrki Kuoppala) writes: > > jkp@joker.hut.fi 'src' 451: ls -lagF > > total 4 > > drwxrwxr-x 4 root staff 512 Aug 25 01:04 ./ > > drwxr-xr-x 6 nobody wheel 512 Aug 23 23:33 ../ > > drwxr-xr-x 2 haa staff 512 Aug 24 16:32 OS-hd-fix/ > > drwxrwxr-x 4 jkp staff 512 Aug 25 01:04 local/ > > jkp@joker.hut.fi 'src' 452: mv OS-hd-fix local > > mv: OS-hd-fix: rename: Permission denied > > "mv" only allows the rename of a directory "only if the the two =============================================================== > directories have the same parent." In this case, the attempted move ================================= (System V) > was to a different directory. Details of why whis is have slipped > from memory but probably have somthing to do with the necessity of > changing the inode number for ".." in the original directory in addition > to changing link counts in the original parent and the new parent. > > Nick Landsberg I don't believe there is a compelling reason (except as forbidden by permissions) to restrict mv from moving a directory to a new location within the same file system. If the target location was to another directory, you would however have to check that the file system hasn't changed. Their added restriction just avoids having to check. If mv allows the target location to be in a different file system, there's no a priori way of knowing if the mv will succeed without trying it. Then mv runs the risk of throwing your forty million blocks rooted at OS-hd-fix over the wall into it's new location only to discover that the one remaining block won't fit ... then, what's the poor guy to do? Assuming that problem is solved, consider the case where OS-hd-fix lives in file system A and has file system B mounted on a subdirectory. How do you mv OS-hd-fix into file system B? So, they probably did it that way to avoid saddling mv with semantics only someone from Berkeley could understand :-). Don Eastman
jkp@cs.HUT.FI (Jyrki Kuoppala) (08/26/89)
In article <647@cbnewsi.ATT.COM>, npl@cbnewsi (nickolas.landsberg) writes: >In article <24612@santra.UUCP> jkp@cs.HUT.FI (Jyrki Kuoppala) writes: > > jkp@joker.hut.fi 'src' 451: ls -lagF > > total 4 > > drwxrwxr-x 4 root staff 512 Aug 25 01:04 ./ > > drwxr-xr-x 6 nobody wheel 512 Aug 23 23:33 ../ > > drwxr-xr-x 2 haa staff 512 Aug 24 16:32 OS-hd-fix/ > > drwxrwxr-x 4 jkp staff 512 Aug 25 01:04 local/ > > jkp@joker.hut.fi 'src' 452: mv OS-hd-fix local > > mv: OS-hd-fix: rename: Permission denied > >"mv" only allows the rename of a directory "only if the the two >directories have the same parent." In this case, the attempted move Not so on bsd; you can move directories all over the place, just like files. On the above example, howeer, it seems that I can't move OS-hd-fix because I don't have write permission to the directory OS-HD-fix. If OS-HD-fix were a directory, I would be able to move it. That's why I think this is a bug, either in the kernel or in the documentation (rename(2) doesn't mention the restriction that you should be able to write to the directory moved). The reason that many people have already mentioned is probably that the `..' entry for OS-HD-fix needs to be changed when it's moved. But I don't think that's a valid reason; as the kernel hides the . and .. entries from us by allowing us to say rename(dir1, dir2) IMHO it should also hide the changing of the `..' entry. //Jyrki
cpcahil@virtech.UUCP (Conor P. Cahill) (08/26/89)
In article <Aug.25.20.08.36.1989.12245@pilot.njin.net>, deastman@pilot.njin.net (don eastman) writes: > I don't believe there is a compelling reason (except as forbidden by > permissions) to restrict mv from moving a directory to a new location > within the same file system. If the target location was to another > directory, you would however have to check that the file system hasn't changed. > Their added restriction just avoids having to check. Moves of directories are real bad things that can open lots of cans of headaches. One of them is what happens when you move a directory to a sub-directory of itself. Consider the following: directory structure: /a/dir1/dir2/dir3/dir4/dir5 command: mv /a/dir1 /a/dir1/dir2 command: (in /a/dir1/dir2) mv .. dir3k Another problem is (due to the fact that the move will not be and atomic operation) what happens if the command is interrupted (with a kill -9, so it doesn't have a chance to clean up)? Do we now have a corrupted file system? -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
chris@mimsy.UUCP (Chris Torek) (08/27/89)
In article <1078@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >Another problem is (due to the fact that the move will not be and atomic >operation) what happens if the command is interrupted (with a kill -9, so >it doesn't have a chance to clean up)? Do we now have a corrupted file >system? This is why rename() is in the 4BSD kernel (for `BSD' >= `.2' :-) ). As for the original question, the answer is here, in the beginning of the rename() syscall (ufs_syscalls.c). dp = ndp->ni_pdir; /* * If ".." must be changed (ie the directory gets a new * parent) then the source directory must not be in the * directory heirarchy above the target, as this would * orphan everything below the source directory. Also * the user must have write permission in the source so * as to be able to change "..". We must repeat the call * to namei, as the parent directory is unlocked by the * call to checkpath(). */ if (oldparent != dp->i_number) newparent = dp->i_number; if (doingdirectory && newparent) { if (access(ip, IWRITE)) goto bad; -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
guy@auspex.auspex.com (Guy Harris) (08/27/89)
>One of them is what happens when you move a directory to a >sub-directory of itself. Consider the following: > > directory structure: /a/dir1/dir2/dir3/dir4/dir5 > > command: mv /a/dir1 /a/dir1/dir2 > > command: (in /a/dir1/dir2) mv .. dir3k Script started on Sat Aug 26 15:38:07 1989 auspex% cat /etc/motd SunOS Release 4.0 (AUSPEX) #1: Thu Jun 1 06:56:44 PDT 1989 auspex% mv /tmp/dir1 /tmp/dir1/dir2 mv: /tmp/dir1: rename: Invalid argument auspex% cd /tmp/dir1/dir2 auspex% mv .. dir3k mv: ..: rename: Invalid argument auspex% ^D script done on Sat Aug 26 15:38:22 1989 SunOS and, I think, other systems that have picked "rename" up from 4.xBSD, won't let you do such a move. They will let you do other "safe" moves, though.
glenn@greenber.austin.ibm.com (Glenn Zazulia) (08/29/89)
In article <24612@santra.UUCP> jkp@cs.HUT.FI (Jyrki Kuoppala) writes: >drwxrwxr-x 4 root staff 512 Aug 25 01:04 ./ >drwxr-xr-x 6 nobody wheel 512 Aug 23 23:33 ../ >drwxr-xr-x 2 haa staff 512 Aug 24 16:32 OS-hd-fix/ >drwxrwxr-x 4 jkp staff 512 Aug 25 01:04 local/ > > ... > >According to the documentation (rename(2) and mv(1)) there's no reason >the `mv OS-hd-fix local' shouldn't work. This seems like a bug. > When rename()ing a directory to a different parent directory, it is necessary to have write permission of the directory that is being moved. The reason is that the ".." entry in the directory being renamed needs to be modified to point to the new parent directory. This is one of the few instances when the process needs write access to the file being renamed, and I have never seen this fact documented. Glenn Zazulia >> This .signature intentionally left blank <<