IAM
======
Name:           Reparse Points and Referrals Umbrella Case
Submitter:      Alan Wright
Owner:          Glenn Skinner
Exposure:       open


SUMMARY
=======
        This project is the umbrella case to document the roadmap for
        reparse points and referrals.  The roadmap will be delivered
        in phases and will be documented in subsequent PSARC cases.

        The intent of this case is to provide the overall context and
        motivation to add reparse points by describing an implementation
        (referrals) that will be built on the fundamental infrastructure
        provided by reparse points.



ISSUES
======

 Issues for inception review on 2009-08-05
 
 dwc-1	reparse_umbrella_spec.txt, section 3, 3rd paragraph:
 
 	Are referrals intended to be a useable as a replacement for
 	/net/"host"?
 
     Response:
 	It may be possible to do so but that's not the primary intent for
 	referrals.  Referrals are simply a means to tell a client that it
 	should continue processing a path at an alternate location.
 
 dwc-2	RP.pdf, page 11, 2nd & 3rd bullets:
 
 	In the POSIX and SUS standards, the "@", "{", ":", and "}" are
 	all legal (although not portable) characters in a filename.  The
 	standards explicitly state that the contents of a symlink are
 	used to replace the name of the symlink during pathname
 	resolution.  If you change the meaning of symlink contents
 	starting with "@{" without adding an option to enable this new
 	behavior, you are violating the POSIX and UNIX branding
 	requirements.  (This could easily be why AIX chose to use a new
 	file type.)
 
 	You could use a new system call (e.g., reflink(2) to create a
 	symlink and set the XAT_REPARSE attribute on it as an atomic
 	operation), but having symlink(2) change the meaning of a
 	symlink if it contains some magic characters violates the
 	standards.
 
     Response:
 	The project team considered the effect on standards conformance and
 	feels that there will be no impact.  We are convinced that existing
 	services and applications will not be affected by this change and that
 	standards conformance tests will not detect a non-conformance due to
 	these changes,
 
 	Should an application unintentionally create a symlink with the
 	reparse point format, it will be stored faithfully by symlink(2) and
 	retrieved by readlink(2), and local system and library calls that
 	accept filenames will behave as they do today on encountering it.
 	Since XAT_REPARSE is not visible to POSIX applications, there is no
 	mechanism by which such an application running locally will detect a
 	deviation from normal POSIX behaviour.
 
 	The NFS and SMB follow-on projects will change remote file access
 	semantics but they are already non-POSIX environments, and none of the
 	projects envisioned under this umbrella interpose on local access.
 
 	As described in the case materials, file systems must announce support
 	for this feature (as described in PSARC/2007/227) in order for it to
 	be activated, which, for the current roadmap, will only affect ZFS.
 	The project team is not considering adding reparse point support to
 	any other file systems.
 
 	On the basis that this case will not affect, and cannot be detected
 	by, any existing local behavior, and that only file systems announcing
 	reparse point feature support will trigger XAT_REPARSE behaviour, the
 	project team feels that it is unnecessary to provide an enable/disable
 	option.
 
 dwc-98  Nit: reparse_umbrella_spec.txt, section 3, item 3 under heading
 	"The follow-on projects are:", 2nd paragraph:
 
 	Am I correct in assuming that "hosed and stored" was intended to
 	be "housed and stored"?
 
     Response:
 	Yes, typo.
 
 dwc-99	Nit: RP.pdf, page 12, 3rd bullet:
 
 	Shouldn't "Userpace" be "Userspace"?
 
     Response:
 	Yes, typo.
 

THE NEXT STEP
=============
Close this case when 2009/387, the actual case, is approved to continue