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) >> >> @{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 {} + > 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 > >
