>The only difference it made was if the symlink was in a directory with >the sticky-bit set, (like /tmp) in which case the usual rule that one >needed write access to the object (the symlink itself in this case) as >well as to the directory also applied. In no other case that I'm aware >of does the permission on a symlink matter; it can be followed or >listed even with a permission of 0.
>Whether that case makes it worth implementing (to include any needed >changes to ufsrestore, tar, cpio, pax, etc)...well I don't see it >myself... That case was considered a bug which we fixed, so it's no longer relevant; the mode of a symbolic link is now always ignored (the owner is relevant in sticky directories and for quota purposes) >Another cool thing that I played with was flink()...but the most >interesting case of giving a name back to a file that had its last name >unlinked didn't work, due to a check for that very case in some other >kernel code (forgot just where). So I didn't go anywhere with that one >either. (It would've been nice to have a nameless file that would go >away if a program died, but could have had its name restored to it if >the program successfully created the desired contents; so that the file >would only be visible to any other program if it was complete.) The check in ufs prevents linking of files with a link count of 0. /proc can be used for "flink" but again it is hampered by the same check. (ln /proc/<pid>/fd/<num> /some/place/in/the/same/fs: on ufs/tmpfs this fails with ENOENT when the link count is 0 but works in other cases; on zfs it fails with cross device link, always) Casper _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
