Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!snorkelwacker!bloom-beacon!bloom-beacon!jik
From: jik@pit-manager.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.wizards
Subject: Re: Hard links to directories: why not?
Message-ID: <1990Jul23.083256.17790@athena.mit.edu>
Date: 23 Jul 90 08:32:21 GMT
References: <18461@rpp386.cactus.org> <1990Jul22.035130.12559@zoo.toronto.edu>
	<18466@rpp386.cactus.org> <3724@auspex.auspex.com>
	<18468@rpp386.cactus.org>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: /mit/jik/.organization
Lines: 28
In-Reply-To: jfh@rpp386.cactus.org's message of 23 Jul 90 04:25:33 GMT


  Are /dev and /usr/tmp on your machine on different partitions?  If
so, then the behavior of mv is understandable.

  Older versions of mv couldn't move files between partitions at all,
since rename() doesn't work between partitions.  Newer versions first
attempt to use rename() to change the name of a file, and if that
fails because the rename() attempted to rename a file to a different
partition, than it uses the same method as cp to copy the file.

  Therefore, if /usr/tmp and /dev are on different partitions on your
system, then the rename() is going to fail, so mv is going to create a
file of the specified name in /usr/tmp, then open /dev/null for read
and copy its "contents" into the file in /usr/tmp.

  The "correct" solution, perhaps, is to make mv check for special
files after the rename() fails, and to use the mknod code to recreate
special files.  The problem with this is that it would require mv to
be setuid.  Perhaps a better solution would be for mv to notice
special files and print out an error like "cannot rename special files
across partitions"; that is, after all, what it used to print when you
tried to mv regular files across partitions (without the word
"special").

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