Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!bloom-picayune.mit.edu!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.questions
Subject: Re: removing hard linked directories
Message-ID: <1991Mar21.100031.12027@athena.mit.edu>
Date: 21 Mar 91 10:00:31 GMT
References: <1991Mar20.013744.12749@ux1.cso.uiuc.edu> <1991Mar20.115508.25638@athena.mit.edu> <1991Mar21.025311.9821@nmt.edu>
Sender: news@athena.mit.edu (News system)
Organization: Massachusetts Institute of Technology
Lines: 37

In article <1991Mar21.025311.9821@nmt.edu>, rmilner@zia.aoc.nrao.edu (Ruth Milner) writes:
|> Scenario: directory in /tmp belonging to someone else. I forget it isn't
|> mine, come along (just me, not root) and mv it. Result: mv says "not
|> owner", but by that time it has already created the new directory *and did
|> not clean it up*. Not nice.

  Sounds like you've got an odd version of mv.  Here's what happens on my
(4.3BSD-like) system:

	% pwd
	/site/tmp
	% ls -ldg foo
	drwxrwxr-x  2 daemon   wheel         512 Mar 21 04:55 foo/
	% whoami
	jik
	% mv foo bar
	mv: foo: rename: Not owner
	% ls -ldg foo bar
	bar not found (No such file or directory)
	drwxrwxr-x  2 daemon   wheel         512 Mar 21 04:55 foo/

In other words, if the mv fails, the mv fails.  Indeed, I believe that the mv
command is documented as guaranteeing that if the rename fails, the original
file is left unchanged and undamaged.

  Staring at the source code for mv on my system, it appears that directories
are moved using an atomic rename system call.  If your mv is behaving as
you've described, then either (a) the rename system call in your kernel is
brain-damaged, or (b) you've got a brain-damaged version of mv.

  What kind of machine and OS are you working on?

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710