Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!gatech!udel!mmdf
From: HELMER%SDNET.BITNET@vm1.nodak.edu (Guy Helmer)
Newsgroups: comp.os.minix
Subject: Re: Replacement for rename()?
Message-ID: <20596@louie.udel.EDU>
Date: 27 Jul 89 15:45:55 GMT
Sender: mmdf@udel.EDU
Lines: 30

Dermont Tynan writes:
>In article <20510@louie.udel.EDU>, HELMER%SDNET.BITNET@vm1.nodak.edu (Guy
> Helmer) writes:
>
>> Under minix, link("/tmp/oldfile", "/tmp/newfile") doesn't work for
>> me.  When I tried it, this path traversed a mount point on my system, but
>> I (apparently incorrectly) hoped that it would still work.
>> I don't have V7 docs nor do I have real un*x to try this out,
>> so I don't really know what is supposed to work.
>
>I don't understand this.  You're not crossing any mount points with this
>one.  If Minix doesn't allow you to do the link, then Minix is broken.
>What error-code is returned by 'link'???  Have you looked in the source?
>(You *do* have a Minix source licence, don't you :-)
Yes!  At least I should :-))
>Your chdir() version should work also, although it is an ugly hack, and
>should only be used as a temporary measure.  The reason 'link' won't
>allow you to cross a mount point, is because the true ID for a file, is
>not just its inode, but the dev/inode pair.  As such, an inode on one
>device has no meaning on another device.  In your case above, both files
>are on the same filesystem, and Minix has no excuse not to link them
>together.
>						- Der

I jumped the gun when I blamed link() for not working.  I forgot my un*x
internals and thought that link() knew that "/tmp/whatever" was a path
that was crossing mount points as it was parsing the path;
I then thought maybe link() assumed that it couldn't link the files.
My mistake, and sorry for the inconvenience to everyone.
-- Guy Helmer