Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!uunet!virtech!cpcahil From: cpcahil@virtech.UUCP (Conor P. Cahill) Newsgroups: comp.unix.wizards Subject: Re: rename strangeness, a possible bug Message-ID: <1078@virtech.UUCP> Date: 26 Aug 89 16:18:31 GMT References: <24612@santra.UUCP> <8352@boring.cwi.nl> <647@cbnewsi.ATT.COM> Organization: Virtual Technologies Inc Lines: 26 In article , 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 | +-----------------------------------------------------------------------+