bugfindutils - Bugs: bug #51926, -xtype l fails on symbolic links...

 
 

bug #51926: -xtype l fails on symbolic links that have a loop

Submitted by:  James Youngman <jay>
Submitted on:  Sun 03 Sep 2017 12:35:20 PM UTC  
 
Category: findSeverity: 4 - Important
Item Group: Wrong resultStatus: None
Privacy: PublicAssigned to: James Youngman <jay>
Originator Name: YorickOpen/Closed: Open
Release: NoneFixed Release: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Thu 07 Sep 2017 02:03:38 AM UTC, comment #6:

Re: "In fact the error can occur even when you wouldn't expect it due to find's arm-swapping optimizations:"

That's actually a flat-out error; you shouldn't do optimizations that cause additional exceptions.

Dale Worley <worley>
Wed 06 Sep 2017 05:21:02 PM UTC, comment #5:

In fact the error can occur even when you wouldn't expect it due to find's arm-swapping optimizations:

$ ln -s loop loop
$ find -links 100 -xtype l
find: ‘./loop’: Too many levels of symbolic links

Even though -xtype appears guarded by the -links test, it's been re-ordered in front of it and thus causes an error.

Tavian Barnes <tavianator>
Tue 05 Sep 2017 07:54:21 PM UTC, comment #4:

&gt; It turns out that find treats &quot;-xtype (anything)&quot; as false on a broken link, which doesn't seem to be specified in the manual page. So it would be plausible to treat it as false on a circular link as well.

Not really:

$ ln -s nowhere broken
$ find -xtype l
./broken

That behaviour is documented here: https://www.gnu.org/software/findutils/manual/html_node/find_html/Type.html

As far as what to do when encountering a symbolic link loop, I think it makes sense to consider them the same as other forms of broken symbolic links.

Tavian Barnes <tavianator>
Tue 05 Sep 2017 02:23:41 AM UTC, comment #3:

The complexity is that "-xtype" isn't really defined for a looping link, because xtype is a test of the thing at the end of the chain of links (which doesn't exist).

Actually, there's a similar problem with an ordinary broken link (which doesn't point to anything).

It turns out that find treats "-xtype (anything)" as false on a broken link, which doesn't seem to be specified in the manual page. So it would be plausible to treat it as false on a circular link as well.

There may be an upward-compatibility problem that some users are expecting to get the "Too many levels of symbolic links" message.

Dale Worley <worley>
Sun 03 Sep 2017 09:26:33 PM UTC, comment #2:

Correction: find isn't failing to search the directory, it's just that in "find -L -xtype l -print" the "-xtype l" test fails for symbolic link loops (whereas it would succeed for broken symbolic links).

James Youngman <jay>
Project AdministratorIn charge of this item.
Sun 03 Sep 2017 09:15:15 PM UTC, comment #1:

I think it's OK to issue a diagnostic (with -L) but the rest of the directory should be searched:

$ ./find/find /tmp/test/ -ls
3932161 4 drwxr-xr-x 2 james james 4096 Sep 3 13:15 /tmp/test/
3932162 0 lrwxrwxrwx 1 james james 1 Sep 3 13:14 /tmp/test/a -> a
3932164 0 -rw-r--r-- 1 james james 0 Sep 3 13:15 /tmp/test/c
3932166 0 -rw-r--r-- 1 james james 0 Sep 3 13:15 /tmp/test/e
3932163 0 -rw-r--r-- 1 james james 0 Sep 3 13:15 /tmp/test/b
3932165 0 -rw-r--r-- 1 james james 0 Sep 3 13:15 /tmp/test/d
3932167 0 -rw-r--r-- 1 james james 0 Sep 3 13:15 /tmp/test/f

$ ./find/find -L /tmp/test/ -ls
3932161 4 drwxr-xr-x 2 james james 4096 Sep 3 13:15 /tmp/test/
./find/find: ‘/tmp/test/a’: Too many levels of symbolic links
3932164 0 -rw-r--r-- 1 james james 0 Sep 3 13:15 /tmp/test/c
3932166 0 -rw-r--r-- 1 james james 0 Sep 3 13:15 /tmp/test/e
3932163 0 -rw-r--r-- 1 james james 0 Sep 3 13:15 /tmp/test/b
3932165 0 -rw-r--r-- 1 james james 0 Sep 3 13:15 /tmp/test/d
3932167 0 -rw-r--r-- 1 james james 0 Sep 3 13:15 /tmp/test/f

James Youngman <jay>
Project AdministratorIn charge of this item.
Sun 03 Sep 2017 12:35:20 PM UTC, original submission:

find should not fail on any situation normally found in a file system, except in cases where it cannot recover safely (e.g. someone it attempting to exploit a file system race condition, perhaps).

Having a loop of symbolic links is "broken" in some sense, but this should not cause find to fail. Unfortunately, if -xtype is used, fid does fail:

/tmp/test$ ls -l
total 0
lrwxrwxrwx 1 james james 1 Sep 3 13:14 a -> a
-rw-r--r-- 1 james james 0 Sep 3 13:15 b
-rw-r--r-- 1 james james 0 Sep 3 13:15 c
-rw-r--r-- 1 james james 0 Sep 3 13:15 d
-rw-r--r-- 1 james james 0 Sep 3 13:15 e
-rw-r--r-- 1 james james 0 Sep 3 13:15 f
/tmp/test$ find . -xtype l -ls
find: ‘./a’: Too many levels of symbolic links
/tmp/test$ echo $?
1

The original bug report is GNU *debbugs) bug 28079: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28079

James Youngman <jay>
Project AdministratorIn charge of this item.

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by ruv (want to follow)
  • -unavailable- added by tavianator (Posted a comment)
  • -unavailable- added by worley (Posted a comment)
  • -unavailable- added by jay (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 30 Nov 2017 11:27:22 AM UTCruvCarbon-Copy-=>Added ruv

    Back to the top


    Powered by Savane 3.1-cleanup1