Robert Thurlow wrote:
> Darren J Moffat wrote:
>
>> What happens if open(2) is called with O_NOFOLLOW set on one of these
>> reparse points ? (Please answer for ZFS local access, NFS and CIFS).
>
> For a process opening a symlink on ZFS, current behaviour in the
> open(2) man page should be seen (open() results in -1/ELOOP).
> This should also be the short-term behaviour with an open done
> on NFS and CIFS filesystems.
>
> In the longer term (and after delivering software to be defined
> in future cases), the intent is to have NFSv4 and CIFS return
> referrals instead of making the symlinks visible to the clients.
>
>> So why not just a system attribute to store the whole thing ?
>> Particularly since it is required to store a system attribute to
>> distinguish a reparse point from a normal symlink anyway.
>
> Archivers that slurp and spit the symlink contents will work
> without mods as long as they get all of the bytes, but would
> need more extensive modifications if our storage was in a
> system attribute. Also, we can get the single bit we need
> in ZFS now, and a 16K sysattr will not be supportable for a
> few more months.
I'm confused. Brian says that archivers Just Work with the current
form, because the attributes are retained. Yet, you're saying that the
attributes are not necessarily retained. Which is it? Right now,
either way, you have an attribute... which I *think* means that the you
need support (which may or may not be present) in the archivers.
I actually wonder if a different approach to this would be better -- say
a per-filesystem tunable that enables parsing of symbolic links, then a
simple -- *short* -- magic token that activates it. Say @@ or
somesuch. (Simpler is better here.) The filesystem tunable would be
available for administrators that don't want to use referrals, and have
@@ (or whatever the magic token is) references already in their
filesystems...
-- Garrett
