Karsten M. Self wrote:
on Mon, Feb 17, 2003 at 10:18:46AM +0100, Jeff Elkins (jeffelkins@earthlink.net) wrote:Is there one, or if so is it perceptible? For instance, I compiled kde and qt to live in /opt. If I moved /opt to /usr/local/kde31 and made /opt a symlink would this create overhead a human would notice?$ ls -l /lib /usr/lib You'll find that *every* (almost) system library is implemented as a symlink. The reason for this[1] is that creating or modifying a symlink is an atomic operation. Deleting and creating a file is two separate operations. If you're updating the library that's used by the function you're using to update the library, you're sort of stuck.
You really get the best atomicity, when needed, by using this: ln -sfRemember that the original symlink must be removed, and if that's done in a separate step for libc, or ld-linux, which ln depends on, the subsequent ln command, to create the link, won't work!
There is a discussion about this in 'Running Linux', p. 182 in the Second Edition.
By using symlinks, filehandle open to the old library will continue towork while they are open.
Are you *sure* this is a reason to use symlinks? I really thought old libraries stuck around until all filehandles to them were closed anyway.
I thought it was more that you don't want to just start overwriting the old library directly, because *new* opens by other programs might have a problem until the copy finishes. On the other hand, maybe the overwrite would try to do an exclusive lock on the library, and not work while the library was open by other programs. I'm not inclined to try on my system. :-)
I admit I'm a bit unclear on these points.
1. I know I'm butchering this somewhat. Corrections appreciated.
I hope. :-)