mvdir: where is it, how can I get it?

[Randy Orrison]

In article <16129 at shemp.CS.UCLA.EDU> cc1 at cs.ucla.edu (Michael Gersten) writes:
|First: mymvdir dir1 dir2 (renaming in the current directory)
|mymvdir will link the two, then unlink the first. This will result in an
|extra link count for the inode initially, then a normal link count. The id
|inode has not changed, so dir1/*/.. (now dir2/*/..) has the correct inode number.
Ok.

|Second: mymvdir dir1 dir2/dir1 (putting into a sub directory)
|Once again, the inode in use will be the same. Therefore, any ..'s, .'s, or
|others will still have the correct inode number.
No, the '..' entry in dir1 will have to be changed from whatever it was to
dir2, otherwise doing 'cd ..' from dir1 after this will put you in dir1's old
parent.

|Third: mymvdir dir1 dir1/dir2
|This will cause problems. After dir1 is unlinked, there will be no file for that
|inode/directory that can be referenced. 
Simple to solve, though: don't allow it.  Remember to check for aliases,
though.  (e.g.  mv dir1 ../dir1/dir2)

|Fourth: current directories.
|As I understand it, a process's current directory is just the inode number
|of the directory, and the disk sectors are read in from the buffer pool as
|needed. Since the inodes are still the same, and directory writes (since the
|names have been changed) go into the buffer pool immediately, this should not
|be a problem.
I'm not sure about this.

|Bottom line: I have spent 3 days poking at this, and can find no problem other
|than security, or if the user makes a mistake. So, can anyone tell me why I
|should not make this availible for myself?
For yourself:  go ahead, it's your system.  You're the one that will have to
fix it if anything goes wrong.  I looked at #2 above for a couple seconds and
found a problem you missed.  I certainly wouldn't expect there not to be any
more.

	-randy