Hugh McIntyre <lists at mcintyreweb.com> wrote:
> Joerg Schilling wrote:
> > "Alan.M.Wright" <amw at sun.com> wrote:
> >
> >>> How will you prevent prople from removing these "reparse points" because
> >>> they
> >>> assume 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
> > accidentally
> > also remove these objects?
>
> To be fair, if you have a symlink to an automounted file or directory
> and the server is temporarily not accessible or automounter not running,
> I suspect you'll similarly think the link is dangling. So you'd better
> hope the automounter is in good shape and you have no network glitches
> before using the "find" command above.
In your example, there will be a timeout and other hints that may allow
you to distinguish between a hung server and a non-existing target.
> But this raises the point that if these special reparse symlinks were
> implemented such that the reparsing also happened when the filesystem is
> mounted locally via mount_zfs or mount_lofs, not just remotely over CIFS
> or NFSv4, then most of the issues would go away.
As I did not see a sufficient descption that could help me to understand what
the intention of these reparse points is, I cannot discuss related issues.
> In other words if open(), stat(), nftw(), and similar system calls
> locally on the server hosting the files (including LOFS) access the
> linked-to file, most code will think the link is OK. Since in this
> case, "find -L" should point to the target of the reparse point (which
> hopefully exists).
nftw is not a "system call" and previous versions did have massive problems
and Sun's /bin/find -follow did go into directory loops in case that there have
been e.g. symlinks with a "." target name. This was the reason for writing
sfind in August 2004 but it seems to have been fixed now...
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
