Alan.M.Wright wrote:
> We are reserving '@{...}', i.e. the name must start with @{ and end with }.
>
> We considered both a global option and per file system options but, on
> the basis that no-one could identify a scenario in which something would
> misinterpret these objects and behave badly, we decided not to propose
> an enable/disable switch.
So that fact that you can today create a symlink pointing to such a file
isn't a case of behaving badly ?
estale:pts/83$ echo "hello world" > "@{REPARSE:NFS:00000}"
estale:pts/83$ ln -s @\{REPARSE:NFS:00000\} @\{REPARSE:NFS:00001\}
estale:pts/83$ ls -l
total 2
-rw-r--r-- 1 darrenm staff 12 Jul 14 12:03 @{REPARSE:NFS:00000}
lrwxrwxrwx 1 darrenm staff 20 Jul 14 12:04
@{REPARSE:NFS:00001} -> @{REPARSE:NFS:00000}
estale:pts/83$ cat @\{REPARSE:NFS:00000\}
hello world
estale:pts/83$ cat @\{REPARSE:NFS:00001\}
hello world
Just because you don't create files beginning @{ and ending } doesn't
mean they don't exist. Given all the rest of the data that has to be in
there I think the changes are very very slim. The issue isn't so much
with the REPARSE but the reserving of all @{...} which this case claims
to do. Again I think the chances of a problem are slim but there must
be a reason why BSD made this optional, no ?
Note I'm no longer arguing against the case I'm just recording the fact
that there is a risk in reserving this symlink content namespace though
it is a very small one.
Given everything I've said and the discussion that has been had I'm now
okay supporting this case and give it my @{PSARC:+1}.
--
Darren J Moffat
