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 --