2009/387 [Pathname Reparse Points]

[Alan.M.Wright]

Joerg Schilling wrote:
> Glenn Skinner <glenn.skinner at sun.com> wrote:
>
>   
>> 4. Technical Description:
>>     4.1. Details:
>>
>>        INTRODUCTION
>>     
> ...
>
>   
>> 	 To distinguish a regular symlink from a reparse point, an
>> 	 extensible system attribute will be set on the symlink.  This
>> 	 system attribute is only one bit which indicates whether or
>> 	 not a symlink contains reparse data.
>>     
>
> How exactly will these "reparse points" be distinguished from symlinks?
>   

Precisely as described in the paragraph you quoted.
Otherwise, the assumption was that they would be treated
as any other symlink.

>> 	 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)
>> 	  
>> 	 @{REPARSE@{service-type1:data} [@{service-type2:data}]...}
>> 	  
>> 	 Where some examples of service-type are:
>>        
>> 	 #define REPARSE_SVC_SMB	"SMB"
>> 	 #define REPARSE_SVC_NFS	"NFS"
>> 	 #define REPARSE_SVC_HSM	"HSM"
>> 	  
>> 	 The data for each service will be in string format, which is
>> 	 expected to be typically a UUID string.
>>
>> 	 The pattern above starts with "REPARSE" to distinguish it from
>> 	 a other magic links, such as those supported by BSD.  Note
>> 	 that this case is not a proposal to support BSD magic links,
>> 	 the intent is to avoid precluding the future addition of full
>> 	 BSD magic link support.
>>     
>
> How will you prevent prople from removing these "reparse points" because they
> asume that this are symlinks that point to nowhere?
> Note that the official POSIX method for removing symlinks that do not point
> to a target is:
>
> 	find -L . -type l -exec rm {} +
>   

Symlinks containing reparse data can be removed in the same way as
any other symlink.  There are no special rules, conditions or restrictions.

>
>   
>> 	 The symlink target size should be increased to 16K to
>> 	 accomodate the maximum size supported for MS-DFS referrals by
>> 	 Windows.  Applications are expected to query the PATH_MAX and
>> 	 SYMLINK_MAX values on the local system using
>> 	 pathconf(2)/fpathconf(2).  The value of SYMLINK_MAX would be
>> 	 changed to 16K on ZFS.  The value of PATH_MAX will not be
>> 	 affected.
>>     
>
> Whill SYMLINK_MAX from limits.h be set to 16k?
>   

No.

>              
>   
>>        Operation Flow Example
>>             
>> 	 Here is a simplified example of operation for a CIFS client
>> 	 that tries to access a file where the path contains a DFS
>> 	 link:
>>             
>> 	 a) Client tries to access \\srv\root\...\link\...\file.txt
>> 	    where:
>> 	       'root' is a share (namespace root)
>> 	       'link' is a reparse point seen as a folder by client
>>     
>
> Is this is a typo and you accidently used '\\' as path name separator instead 
> of the official path name separator '/'?
>   

As described in the example, this is what a _CIFS_ client would send
to a CIFS Server.  CIFS clients are often Windows, which uses '\'.
CIFS Servers handle slash translation such that '\' is not presented to
the local operating system.

>  	  
>   
>>        NFS REFERRAL IN OTHER UNIXES
>>             
>> 	 FS referrals have been implemented in other major UNIX
>> 	 distributions such as Linux, AIX and HP-UX but there is no
>> 	 unified approach or implementation.
>>
>> 	 Linux, AIX and HP-UX specify referrals as an NFS export
>> 	 option.  The option format is basically the same in all three
>> 	 operating systems (refer=path at host) but the presentation is
>> 	 somewhat different in each case:
>>
>> 	 - In Linux a referral is presented as a mount point.
>> 	 - In HP-UX a referral is a file system partition or logical volume.
>> 	 - In AIX a special object is used to represent a referral.
>>     
>
> Is this intended to be something like the conditional symbolic links that have 
> been in Apollo Domain system 23 years ago?
>   

I'm not familiar with that proposal.  Can you provide details?

Thanks,

Alan

> Jörg
>
>