Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!njin!deastman From: deastman@pilot.njin.net (don eastman) Newsgroups: comp.unix.wizards Subject: Re: rename strangeness, a possible bug Message-ID: Date: 26 Aug 89 00:08:36 GMT References: <24612@santra.UUCP> <8352@boring.cwi.nl> <647@cbnewsi.ATT.COM> Organization: NJ InterCampus Network, New Brunswick, N.J. Lines: 42 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