Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de> wrote:
> "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.
The new reparse system attribute should be documented in the ls
man page and be displayed when using the -/ options.
>> > 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?
>From the find man page:
Using the -L or -follow option is not recommended when
descending a file-system hierarchy that is under the control of
other users. In particular, when using -exec, symbolic links
can lead the find command out of the hierarchy in which it
started. Using -type is not sufficient to restrict the type
of files on which the -exec command operates, because there
is an inherent race condition between the type-check per-
formed by the find command and the time the executed command
operates on the file argument.
The command you cite seems to ignore all of the warnings in here.
Yes it will remove reparse points (as it should) and it looks like there
may be a multiple undesirable side-effects from such a command.
>> >> 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.
Per the specification section that Don referenced, this shouldn't cause
a problem. It is up to the implementation to decide whether or not
the text length returned is acceptable or an error.
> 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.
We have been looking at this for several months and haven't uncovered
any problems. If you have a specific example, we can consider it but,
so far, everything behaves as expected when a symlink contains arbitrary
text or does not refer to an existing object.
Alan
