On Fri, Jul 10, 2009 at 09:34:26AM -0700, Glenn Skinner wrote:
>        The reparse data will be stored as the link target.  The
>        reparse data is not in file system path format, which is the
>        typical format of a link target.  In order to avoid coming up
>        with a totaly new format for reparse data as the link target
>        we decided to adopt the format used by magic links in BSD:
>        (http://www.daemon-systems.org/man/symlink.7.html)
>         
>        @{repa...@{service-type1:data} [...@{service-type2:data}]...}

I see no UI/CLI/API for managing this.  Exposing users to this format
seems most unfriendly.

I think a CLI should be provided if such a complex format is to be used
to store the referral data.  It could be a simple script for all I care.

Also, how about storing referral data in a per-protocol extended
attribute instead of all of it as symlink contents?  That would be much
cleaner since then:

 - the type of the object (symlink, dir, file...) becomes irrelevant
 - one can export that object for some protocols, a referral for others
 - that object could be a symlink with a /net path -- a very nice
   fallback for NFSv3

Does using EAs cause problems with backup tools?  If so, is that really
a big deal?  Wouldn't backup tools that can't backup EAs be problematic
anyways?

Nico
-- 

Reply via email to