Darren J Moffat <Darren.Moffat at Sun.COM> wrote: > Alan.M.Wright wrote: >>> Aren't you already doing that by looking at the new attribute and then >>> only parsing the symlink data if it is tagged as a reparse point. I >>> agree with Nico I think this case should use a system attribute as the >>> "tag" like it does now but store the data in an extended attribute (ie >>> the runat ones) that shouldn't require you wait on any new >>> functionality in ZFS. >> >> We can't do that with this proposal because symlink can't have >> extended attributes. > > The point is NOT to use symlinks at all but to use a file with an > extended attribute.
We've looked at that and similar options in detail within the project team over the past few months. We looked at using files, directories, mount points and introducing a new object type. Each one resulted in issues that seemed insurmountable: using a file to represent a disjoint name space confusing applications that expect to perform normal file operations on it, applications expecting to read or descend into directories, mount points being involved in client-server exchanges and the ramifications of ensuring that a new object type wouldn't result in erroneous behavior. Ultimately, the team came to the conclusion that it wasn't feasible to pursue any of those options and proposed the symlink option. Alan
