rename strangeness, a possible bug
don eastman
deastman at pilot.njin.net
Sat Aug 26 10:08:36 AEST 1989
In article <647 at cbnewsi.ATT.COM>, npl at cbnewsi.ATT.COM (nickolas.landsberg) writes:
> In article <24612 at santra.UUCP> jkp at cs.HUT.FI (Jyrki Kuoppala) writes:
> > jkp at 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 at 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
More information about the Comp.unix.wizards
mailing list