Some Unix history (was Re: [FIX] primRename:toBe: on MacFileDirectory)

Randal L. Schwartz merlyn at stonehenge.com
Tue Apr 10 20:47:14 UTC 2001


>>>>> "Tom" == Tom  <tmb at lumo.com> writes:

Tom> UNIX puts together "rename", "move", etc. into a single call at the OS
Tom> level because it can implement them all pretty much equally efficiently.

In the original days, when Unix fit into 32K and had 22 system calls
and the source to the kernel could be read in a long rainy afternoon
(which I did)...

There was no rename(2)... there was only link(2) and unlink(2).
To move a file, you merely link()ed to the right new place and name,
and when that worked, you unlink()ed it from the old place.  But
if the link() failed with "cross-device link", that meant that you
were trying to go from one disk to another.  In that event, early
/bin/mv used to fork a /bin/cp (which you could see with ps if you
were fast enough) to copy the data, 

Well, that works fine, except for directories.  link()ing from a
directory was verboten for mortals, because it could mess up the nice
directed tree that formed the hierarchical filesystem, and that
linking the right dot-dot needed to be performed manually.  But root
could do anything.  So /bin/mv was setuid root, and the right
user-space checks were made to ensure that this requested link/unlink
pair wouldn't create an isolated part of the tree ("You cannot move
a directory to within itself" errors), and everything was fine.

Until someone figured out how to exploit a window of opportunity in
/bin/mv.  Not to mention that a setuid root program is generally a
prime target for evil people.  Nor that forking /bin/mv to rename a
directory from another program just seemed... ugly.

So, the Boyz at Berkeley invented rename(2), where all the code that
had formerly been in the /bin/mv to handle link/unlink for both files
and directories was now in the kernel, and a simple unprivileged
interface could then be established.  Of course, this rename(2) has to
punt with cross-device link for renaming off-device, so /bin/mv still
has the fallback to /bin/cp when that happens.

I never understood an artificial distinction between rename and move.
Both of them mean "give a different name for this thing".  That's why
/bin/mv does them "both".  It's even odd typing "both" there.  Does
DOS distinguish them?  Did CP/M?  Does MacOS API distinguish them?  If
so, how silly. :)

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn at stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!





More information about the Squeak-dev mailing list