2009/387 [Pathname Reparse Points]

[Alan M Wright]

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