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

 
 

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

Submitter:  James Youngman <jay>
Submitted:  Sun 03 Sep 2017 12:35:20 PM UTC
   
 
Category:  find Severity:  4 - Important
Item Group:  Wrong result Status:  None
Privacy:  Public Assigned to:  jay
Originator Name:  Yorick Open/Closed:  Open
Release:  None Fixed Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group administrator
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>
Group administrator
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>
Group administrator

 

(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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-11-30 ruv Carbon-Copy- Added ruv

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code