>> 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) > >Code pointer? I'd hate to update a now-useless lchmod() just to >confirm that it is indeed now useless.
http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/fs/tmpfs/tmp_subr.c#74 I changed how this worked in '99 with: 4167560 symlinks and other non-files can be removed by anyone from sticky directories The original BSD sticky semantics were, of course, that you needed to be owner; SV changed this to "write access also", but forgot about the special semantics of symlinks (mode ignored), pipes, sockets (things carrying a context of sorts). >That check is a bit of a disappointment, unless there is no other >equally efficient way of doing whatever it's meant to do, or unless >something actually requires that check as such. IMO, resurrecting a >nameless temporary file could be a very handy capability. > >That the hard links to /proc/$$/fd/$N don't work if $N is on zfs...is that >just a limitation for now, or is that intentional and likely to stay that way? I don't know what causes that. Casper _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
