FYI, I played with a loadable version of this back in Solaris 8, just for myself. I decided that since no existing backup/restore/copy utilities knew about lchmod(), it would be nothing but trouble since non-777 symlinks couldn't be restored accurately. So I never bothered to keep it up.
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... 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.) This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
