> > >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)
Code pointer? I'd hate to update a now-useless lchmod() just to confirm that it is indeed now useless. > >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) 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? This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
