>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.
lchmod() is something we really ought to have; not because the permissions
of symbolic links matter but because you don't want to follow links when
you do a chmod.
E.g., with both chown -R and chmod -R you don't want to change what is at
the end of symlinks.
flink() is problematic because it requires you to find the appropriate
device to create the link in AND it may allow you to upgrade the access
to the file. (>E.g., you get a read-only filedescriptor which is hidden
somplace and which has mode 666; flink would allow you to upgrade to
write access.
>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.
>
It doesn't work with UFS, ZFS or tmpfs.
Casper
#!/bin/sh
#
#
# Test flink
#
dir=${1-.}
echo $dir
if [ ! -d "$dir" ]
then
echo "Usage: $0 [directory]" 1>&2
exit 1
fi
f=`mktemp $dir/lnXXXXXX`
echo $f
exec 3>$f
rm -f $f
ls -l /proc/self/fd/3
ln /proc/self/fd/3 $f
rm -f $f
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
