On 07/14/09 04:07, Darren J Moffat wrote:
> 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 ?
I suspect that magic symlink support is optional in BSD because the
content of a magic symlink will be changed on the fly by the OS.
For example, if @{HOST} appears in the symlink that tag will be
replaced at runtime by the nodename.
Nothing in this proposal will modify the content of a symlink on
the fly or inhibit a regular symlink from working as it does now,
including a usable symlink named exactly like a reparse point or
the object being (simultaneously) a symlink and a reparse point.
Alan
> 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}.
>
