ln -f
Lars Henrik Mathiesen
thorinn at skinfaxe.diku.dk
Fri Aug 10 06:07:35 AEST 1990
guy at auspex.auspex.com (Guy Harris) writes:
>>If you use a version of 'ln' that clobbers file2 and replaces it with a
>>link to file1 in an atomic operation, there is no such window.
>As far as I know, there's no such atomic operation, either; I sure
>haven't seen any such operation in any UNIX system I've ever run into.
>Given that, every version of "ln" I know of that removes the target
>first has to first "unlink()" the target, and then do the "link()". As
>such, the window is still there....
Why don't the versions of ln that you know of on 4.3 BSD and SunOS 4
use the rename system call?
idavolde 2 >man rename
...
DESCRIPTION
Rename causes the link named from to be renamed as to. If
to exists, then it is first removed. ...
Rename guarantees that an instance of to will always exist,
even if the system should crash in the middle of the opera-
tion.
I've heard that it was precisely because of the various race
conditions in connection with ln that made Berkeley put the function
into the kernel where inodes could be locked and updates done in
proper order.
--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark [uunet!]mcsun!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers. thorinn at diku.dk
More information about the Comp.unix.wizards
mailing list