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? > 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) > > @{repa...@{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 {} + > 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? > 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 '/'? > 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? J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
