Path: utzoo!attcan!uunet!dino!ux1.cso.uiuc.edu!usenet
From: bruner@sp15.csrd.uiuc.edu (John Bruner)
Newsgroups: comp.unix.wizards
Subject: Re: Hard links to directories: why not?
Message-ID: <1990Jul25.134105.10586@ux1.cso.uiuc.edu>
Date: 25 Jul 90 13:41:05 GMT
References: <3724@auspex.auspex.com> <18468@rpp386.cactus.org> <1990Jul23.083256.17790@athena.mit.edu> <3742@auspex.auspex.com> <1990Jul25.044952.20933@mintaka.lcs.mit.edu>
Sender: usenet@ux1.cso.uiuc.edu (News)
Reply-To: bruner@sp15.csrd.uiuc.edu (John Bruner)
Organization: CSRD, University of Illinois
Lines: 24
In-Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)

In article <1990Jul25.044952.20933@mintaka.lcs.mit.edu>, jik@athena (Jonathan I. Kamens) writes:
>  Yes, before the rename system call existed, all mv's did basically
>the same thing as cp (but they deleted the original after successful
>writing of the copy).  However, when rename was created, many vendors
>(although not all, I'm sure) changed mv to use rename exclusively and
>to fail if the rename failed.  Many of those same vendors have more
>recently once again modified mv to do what the original, pre-rename mv
>did if the rename system call fails because of an attempt at
>cross-device renaming.

Before the rename() system call existed, "mv" attempted to link() the
old name to the new name and then to unlink() the old name.  If the
link() failed (e.g., because it crossed a mount point) then it would
copy the file instead.

I'm not well acquainted with the introduction of rename() into kernels
derived from System V.  When Berkeley implemented rename() they
substituted it for link()/unlink() in "mv" and left the copy code
intact.  If a company shipping a BSD-derived "mv" removed the code
that copies files when rename() fails, then they deserve all of the
criticisms that can be sent their way.
--
John Bruner	Center for Supercomputing R&D, University of Illinois
	bruner@csrd.uiuc.edu		(217) 244-4476