persistant symbolic links

Mildred ml.mildred593 at
Sun Apr 13 14:18:12 PDT 2008


I think we need a way to have persistent symbolic links. Currently we
have two possibilities for symbolic links:

- hard links: perfect but you need to be rot to link directories, there
  is no easy way to know if a file is a link or not and you cannot link
  files across partitions

- symbolic links: that sounds perfect but when the target is moved, the
  link is left unchanged and points to the void. And that's a problem.

I know that Mac OS is addressing that problem and provides methods to
update an alias that had its target moved. And I suspect that Windows
is also thinking of it. Because I have a concrete example where this
could be useful (a software I'm planning that would need this feature),
I would like to propose a standard solution.

First of all, I think that symbolic links should not be changed, and
that they shouldn't be updated unless it is really wanted. My idea is
to have a light daemon running at the system level that would be
accessed by dBus and will update links that were registered to it. If a
link is not registered, it is not updated.

So now, how are links updated ?

When a link is registered to that daemon, it will ask the kernel
(example: using inotify) to get events related to the link's target
when it is moved or renamed. When a such event happens, the link is
automatically updated.
Of course, the daemon should store a list of all monitored links to
continue monitoring symlinks across reboots.

But that's not enough yet. How about targets that lives in an external
hard drive that gets renamed or moved on another computer ?

Well, the daemon, when asked to monitor a a symlink, should add as
extended attributes to the symlink file the following information:
- the UUID of the filesystem where thetarget is located
- the inode number of the target
- an information to advertise this link is being updated

When a partition is mounted, and if any symlink in the system pointing
to a file in this partition is broken, then the daemon should look
(search) the corresponding inode. If it is found, the symlink is
updated. if not, the symlink is declared broken (an information added
to the extended attributes). In any case, if the mount point is
different from the last time the filesystem was mounted, all symlinks
should be updated.

Now, when an application find a symlink that is advertised as being
updated. And if that symlink is broken but not declared as broken in
the extended attributes, the application would be able to ask the
daemon about that specific symlink. The answer could be:
- the target is found and the symlink is updated
- the target is not found and the symlink is declared as broken
- the filesystem where the target could be found is not mounted and the
  symlink is left as it is (or perhaps an information is added to the
  xattrs, but it should be removed as soon as the filesystem is

What do you think about that ?
(if a similar solution exists, excuse me for that post but obviously
that solution is too well hidden and needs to be advertised)

Even though I don't have any experience programming dBus and inotify, I
would like to implement that. But it won't be possible before few
months (say, middle of June). If someone is willing to help me in that
task, I would be really happy.

Last thing, I write that on the spot, so I may not have talked about
all the possible issues and solutions. if you see something, please
answer to bring something constructive.

Mildred Ki'lya
E-Mail:	mildred593(at)

Site:	<>
XMPP:	<mildred at> (GoogleTalk, Jabber)

GPG:	197C A7E6 645B 4299 6D37 684B 6F9D A8D6 [9A7D 2E2B]

More information about the xdg mailing list