> > I've played around in my time with implementations
> of lchmod() and
> > even flink() (hard-link a name to a file
> descriptor on the same filesystem,
> > easier than it sounds, but uninteresting for me
> because other code
> > prevented it from working unless nlink was already
> greater than zero)
> >
> > I've mentioned them before, but not handed out the
> code, since back then
> > it was derived from limited access source; but also
> because I didn't want
> > folks creating dependencies on it.
> >
> > I'm told that the only case I found where lchmod()
> actually mattered
> > (needed write permission on a symlink in a
> sticky-bit directory to delete it)
> > was regarded as a bug, and went away; so unless one
> really has an urge
> > to see lrwxr-xr-x appear, there's no point to it;
> and as I said, the most
> > interesting case for flink() (restoring a name to
> an open-but-deleted file,
> > so that if one crashes, it goes away, but if one
> completes the output,
> > one can reassign it a name and have it persist)
> didn't work, so I'm not
> > sure how much of a point there would be to it
> either. They were both
> > more experiments in orthogonality than anything
> else.
>
> Those are things that clearly belong as system calls
> in the base kernel.
Actually, as I look around more, I see that some other systems
(*BSD, Linux, QNX) have one or both of lchmod(), flink(). One
argument used for both even if they otherwise seem silly is avoidance
of race conditions, although I've seen counter-arguments for flink(),
but I didn't quite understand them - maybe they're Linux-specific.
OTOH, the (I suppose relatively new to Solaris) O_NOFOLLOW and/or
O_NOLINKS open() flags offer some help for some of those situations.
Maybe one or both of those calls might be worth having to help others
in porting code, if nothing else.
Anyone think either or both are worth the bother? I
have my doubts, but I can see it could be argued either way. They're
both rather easy to implement.
>From what's been said previously, maybe flink() could even be implemented
in user space, i.e. something like:
int flink(int fd, const char *path)
{
char buf[32]; /* /proc/XXXXX/fd/YYYYY\0 is only 21 */
snprintf(buf,sizeof buf,"/proc/%d/fd/%d",getpid(),fd);
return link(buf,path);
}
although I seem to recall someone (Casper?) mentioning that didn't work
with some filesystem (ZFS?)...and at least on Solaris 10, I just noticed that
it didn't work either if one was under a lofs mount (the lofs mount in
question was of a vxfs filesystem; if I went to the "real" directory and tried
it worked ok). So given that the userland approach seems to work in less
cases, if it was worth doing, it probably would have to be a syscall.
This message posted from opensolaris.org
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
