"Alan.M.Wright" <amw at sun.com> wrote:

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

This paragraph does not contain the information you claim: "man -k attrubute"
does not lead me to useful information.


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

So you admit that people who intend to remove garbage symlinks will accidentaly
also remove these objects?

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

So I expect existing applications to fail.

>From what I did read on this topic, I expect problems with existing 
applications. I would like to read a description on what happens with typical 
existing applications, if this new feature is implemented.

 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

Reply via email to