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:  find Severity:  4 - Important
Item Group:  Wrong result Status:  None
Privacy:  Public Assigned to:  James Youngman <jay>
Originator Name:  Yorick Open/Closed:  Open
Release:  None Fixed 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)

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 Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can 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
    11/30/2017 ruv Carbon-Copy- => Added ruv

    Back to the top


    Powered by Savane 3.3