2009/387 [Pathname Reparse Points]

[Joerg Schilling]

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