[WARNINGS: long post, containing mostly pointless and possibly inaccurate history]
On Thu, Jun 19, 2008 at 11:35 PM, Philippe Meunier <[EMAIL PROTECTED]> wrote: ... > 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... In BSD 4.4, the system call(s) for changing the timestamps on a file (utime() and utimes()) were made to follow the symlink and affect the linked to file. While the lchown() system call was added later for changing the ownership of a symlink, it seems no felt the timestamps on a symlink was interesting enough to add an lutime() call. It turns out that the next revision of POSIX/SUS will actually add a function that is capable of changing a symlink's timestamps: utimensat() with the AT_SYMLINK_NOFOLLOW flag. This is part of a large set of new functions that let you perform operations on file paths relative to a directory specified via an fd to it; presumably it was felt that as long as a new version of utime* was being specified, this corner case should be eliminated. OpenBSD does not support these new functions at this time; I don't know whether anyone has started work on them. > 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: IIRC, in 4.3 BSD, symlinks worked much like they do now, except that chown(), utimes(), and maybe chmod() did not follow the link but rather operated on the link itself. In 4.4 BSD, symlinks changed significantly: they lost all their metadata and behaved as described on the lstat(2) manpage, inheriting their metadata from the directory they were in. That creates a problem, however: the ownership of a symlink *does* matter in one case: directories with the sticky-bit set, like /tmp. If symlinks don't have independent ownership, then symlinks in /tmp either can only be removed by root or can be removed by anyone, depending on how the check in unlink() was changed. So, the change to strip symlinks of metadata was rolled back and, later, the lchown() system call was added. Interestingly, when symlinks were originally standardized by X/OPEN, the requirements were carefully written to permit the 'no metadata' implementation. That continued when XPG was merged into POSIX to form the Single UNIX Specification. However, the long standing issues with this possibility finally caught up with it and the next version of SUS will require symlinks to have metadata, which is how everyone implements them. ... > 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. Well, there's currently no way to implement a "touch -h" or "chmod -h" in OpenBSD. Oddly enough, while the next SUS does add utimensat() (and fchmodat(), which can change the mode on a symlink), it _doesn't_ add -h options to the touch or chmod commands. If this lack really annoys you, you should take it to the austin-group mailing list (cf. http://www.opengroup.org/). > 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... :-) Yes, they could use updating. Suggesting text to the tech@ list will increase the speed at which that happens... Philip Guenther
