Hello,
After accidentally deleting and recreating a symlink (call it, say,
'slink') to some file ('afile'), I tried to use touch(1) to set the
modification time of slink to be the same as the modification time of
the original symlink I had accidentally deleted (mostly to help me
remember when I created the symlink relative to the other files in
that directory, to help me remember why I created the symlink in the
first place). Of course touch(1) changed the modification time of
afile, not the modification time of slink.
After reading the manpage for symlink(7) I would have expected
touch(1) to have an '-h' option, but it does not. Is there any
special reason why it does not, is this an oversight, or was it just
decided that such feature is so seldom needed that it wasn't worth
implementing? Just curious...
--------------------
While I was at it, I also looked at the manpage for lstat(2): "Unlike
other file system objects, symbolic links do not have an owner, group,
access mode, times, etc. Instead, these attributes are taken from the
directory that contains the link." That's wrong, otherwise there
would be no need for, say, chown(8) to have a '-h' option. Symlinks
also have their own modification time which is obviously not taken
from the directory containing the symlink:
$ mkdir adir; cd adir; touch afile; ls -la
total 8
drwx------ 2 meunier users 512 Jun 20 11:03 ./
drwxr-xr-x 27 meunier users 1536 Jun 20 11:03 ../
-rw------- 1 meunier users 0 Jun 20 11:03 afile
$ sleep 60; ln -s afile slink; ls -la
total 8
drwx------ 2 meunier users 512 Jun 20 11:04 ./
drwxr-xr-x 27 meunier users 1536 Jun 20 11:03 ../
-rw------- 1 meunier users 0 Jun 20 11:03 afile
lrwx------ 1 meunier users 5 Jun 20 11:04 slink@ -> afile
$ sleep 60; touch .; ls -la
total 8
drwx------ 2 meunier users 512 Jun 20 11:05 ./
drwxr-xr-x 27 meunier users 1536 Jun 20 11:03 ../
-rw------- 1 meunier users 0 Jun 20 11:03 afile
lrwx------ 1 meunier users 5 Jun 20 11:04 slink@ -> afile
$
And they have their own access mode which is not taken from the
directory containing the symlink either:
$ chmod g+w .; ls -la
total 8
drwx-w---- 2 meunier users 512 Jun 20 11:05 ./
drwxr-xr-x 27 meunier users 1536 Jun 20 11:03 ../
-rw------- 1 meunier users 0 Jun 20 11:03 afile
lrwx------ 1 meunier users 5 Jun 20 11:04 slink@ -> afile
$
In fact it looks more like a symlink's permissions are simply rwxrwxrwx
with the umask applied to it:
$ umask 753; ln -s afile slink2; ls -la
total 8
drwx-w---- 2 meunier users 512 Jun 20 11:07 ./
drwxr-xr-x 27 meunier users 1536 Jun 20 11:03 ../
-rw------- 1 meunier users 0 Jun 20 11:03 afile
lrwx------ 1 meunier users 5 Jun 20 11:04 slink@ -> afile
l----w-r-- 1 meunier users 5 Jun 20 11:07 slink2@ -> afile
$
Both the man page for chmod(1) and the source code for it indicate
that symlinks do not have modes though, and chmod(1) does not have a
'-h' option, so between that and what the manpage for lstat(2) says, I
think it's not very clear for the reader where the modes for slink and
slink2 above are really supposed to come from. In fact, if I remember
my OS textbooks correctly, I'm quite sure symlinks are just plain
files with just a special bit in the mode indicating their symlink
status, and with the name of the file they point to as their content
(hence the 5 bytes of slink and slink2 above).
I guess that, since symlink modes are never used to check permissions,
chmod(1) simply doesn't provide any option to change them once the
symlink has been created. Same thing for the modification time and
touch(1), I assume (though I'd argue that in this case having a '-h'
option might be useful in some cases --- see above). But that's quite
different from pretending the modes and times simply don't exist.
There's probably a lot of history involved here, but IMHO it would be
nice if the man pages for lstat(2) and chmod(1) could be fixed /
clarified to tell the story straight rather than tell confusing
partial truths that do not really match reality. Just saying... :-)
Philippe
