views:

346

answers:

3

Does any operating system provide a mechanism (system call - not command line program) to change the pathname referenced by a symbolic link (symlink) - other than by unlinking the old one and creating a new one?

The POSIX standard does not. Solaris 10 does not. MacOS X 10.5 (Leopard) does not.

Is there anything that does?

(I'm expecting that the answer is "No".)


Since proving a negative is hard, let's reorganize the question.

If you know that some (Unix-like) operating system not already listed has no system call for rewriting the value of a symlink (the string returned by readlink()) without removing the old symlink and creating a new one, please add it - or them - in an answer. Since that means there probably won't be a single 'acceptable' answer, I'm converting to Community Wiki.

+5  A: 

AFAIK, no, you can't. You have to remove it and recreate it. Actually, you can overwrite a symlink and thus update the pathname referenced by it:

$ ln -s .bashrc test
$ ls -al test
lrwxrwxrwx 1 pascal pascal 7 2009-09-23 17:12 test -> .bashrc
$ ln -s .profile test
ln: creating symbolic link `test': File exists
$ ln -s -f .profile test
$ ls -al test
lrwxrwxrwx 1 pascal pascal 8 2009-09-23 17:12 test -> .profile

EDIT: As the OP pointed out in a comment, using the --force option will make ln perform a system call to unlink() before symlink(). Below, the output of strace on my linux box proving it:

$ strace -o /tmp/output.txt ln -s -f .bash_aliases test
$ grep -C3 ^unlink /tmp/output.txt 
lstat64("test", {st_mode=S_IFLNK|0777, st_size=7, ...}) = 0
stat64(".bash_aliases", {st_mode=S_IFREG|0644, st_size=2043, ...}) = 0
symlink(".bash_aliases", "test")        = -1 EEXIST (File exists)
unlink("test")                          = 0
symlink(".bash_aliases", "test")        = 0
close(0)                                = 0
close(1)                                = 0

So I guess the final answer is "no".

Pascal Thivent
Doesn't the '-f' option force 'ln' to do the unlink() then symlink() system calls?
Jonathan Leffler
It does. But the question might have been perceived as "how do I do that in one step" and then it boils down to the definition of "step" - command line? syscall?
Michael Krelin - hacker
I've just noticed that you added syscall wording to your question ;-)
Michael Krelin - hacker
About the `--force` option, the man says "*remove existing destination files*". I don't know if this implies a call to unlink().
Pascal Thivent
@Pascal: it does. On Solaris, the output from 'truss ln -s p x' and 'truss ln -s -f p x' shows an unlink() call before the symlink() call in the second case (and a failed symlink() call in the first). I would expect that to apply to most if not all variants of Unix.
Jonathan Leffler
@Jonathan Thanks for your answer
Pascal Thivent
+2  A: 

Wouldn't unlinking it and creating the new one do the same thing in the end anyway?

matt b
Why unlink in the first place? Why not simple overwrite it?
S.Lott
The net result is approximately the same - but the owner and group and last modified times (and probably inode number) would all be different, in general.
Jonathan Leffler
S.Lott, because you can't.
Michael Krelin - hacker
@S.Lott: what system call does the 'overwrite'? In POSIX, there is no such call. In Solaris and MacOS X, there is no such call. Is there a call to do that on ... Linux, AIX, HP-UX, anything else that looks like Unix? Windows doesn't really have symlinks in the same way, AFAICT, so it is not critical to my analysis - but information about the equivalent Windows API would be useful.
Jonathan Leffler
@Jonathan Leffler: Ummm.... the `ln --force` command will absolutely overwrite an existing link.
S.Lott
Guys, I think you are talking at cross purposes. S.Lott is discussing an executable `ln (1)`, while matt b. is discussing the fact that `symlink (2)` does *not* support overwriting. You are both right, and I would suggest that looking at the implementation of `ln (1)` would give the most idomatic way of accomplishing the unlink-relink procedure.
dmckee
Actually I just didn't know that ln had a --force argument :(
matt b
+1  A: 

It is not necessary to explicitly unlink the old symlink. You can do this:

ln -s newtarget temp
mv temp mylink

(or use the equivalent symlink and rename calls). This is better than explicitly unlinking because rename is atomic, so you can be assured that the link will always point to either the old or new target. However this will not reuse the original inode.

On some filesystems, the target of the symlink is stored in the inode itself (in place of the block list) if it is short enough; this is determined at the time it is created.

Regarding the assertion that the actual owner and group are immaterial, symlink(7) on Linux says that there is a case where it is significant:

The owner and group of an existing symbolic link can be changed using lchown(2). The only time that the ownership of a symbolic link matters is when the link is being removed or renamed in a directory that has the sticky bit set (see stat(2)).

The last access and last modification timestamps of a symbolic link can be changed using utimensat(2) or lutimes(3).

On Linux, the permissions of a symbolic link are not used in any operations; the permissions are always 0777 (read, write, and execute for all user categories), and can't be changed.

mark4o
@mark4o: The Good - The reference to lchown() and ownership in a sticky-it directory is useful - thanks. I was aware of lchown() and it wasn't material to my thesis. I was also aware of sticky-bit directories; I think that the ownership is almost a standard consequence of the rules - the difference, and presumably why it is called out, is that normally you can remove a file if you can write to it, and nominally, anyone can write to a symlink because of the 777 permissions, but in this case, the rules are slightly different.
Jonathan Leffler
@mark4o: The Not So Good - the command sequence shown doesn't do what you think it does (at least, in the scenario: `set -x -e;mkdir junk;(cd junk;mkdir olddir newdir;ln -s olddir mylink;ls -ilR;ln -s newdir temp;ls -ilR;mv temp mylink;ls -ilR;);rm -fr junk`). If you create files oldfile and newfile instead of directories and run the equivalent script (mainly changing olddir to oldfile, newdir to newfile), then you get the effect you were expecting. Just one extra complexity! Thank you for the response.
Jonathan Leffler