findutils - Bugs: bug #54263, find -L treats ENOENT and ENOTDIR...

Group

Main
- Main
- View members
- Search
Homepage
Download
Mailing lists
Source code
Bugs
- Submit new
- Browse
- Reset to open
- Digest
- Dependencies
- ~~Export~~
- Get statistics
- Search
Patches
- ~~Submit new~~
- Browse
- Reset to open
- Digest
- Dependencies
- ~~Export~~
- Get statistics
- Search
News
- Browse
- Atom feed
- ~~Submit~~
- ~~Manage~~

bug #54263: find -L treats ENOENT and ENOTDIR differently

Submitter:	Tavian Barnes <tavianator>
Submitted:	Sat 07 Jul 2018 07:39:49 PM UTC


Category:	find	Severity:	3 - Normal
Item Group:	Wrong result	Status:	None
Privacy:	Public	Assigned to:	berny
Originator Name:		Open/Closed:	Open
Release:	4.6.0	Fixed Release:	None

* Mandatory Fields

Add a New Comment Rich Markup

Tue 18 Sep 2018 03:04:44 PM UTC, comment #2: > find -L . -type l prints a list of symbolic links reachable from the current directory that do not resolve to accessible files. Hmm. I never considered this before, but does the use of "accessible" here imply that EACCES should also count?	Tavian Barnes <tavianator>
Sat 28 Jul 2018 05:11:59 PM UTC, comment #1: Reading the specification again: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html -L [...]. If the referenced file does not exist, the file information and type shall be for the link itself. This means that an error should not be thrown for broken links (well, probably only for primitives that require the symlink to be resolved like '-printf %Y'). And later on: Since the -L option resolves all symbolic links and the -type l primary is true for symbolic links that still exist after symbolic links have been resolved, the command: find -L . -type l prints a list of symbolic links reachable from the current directory that do not resolve to accessible files. The spec does not differentiate between ENOENT and ENOTDIR here. So the current behavior seems to be debatable, at least. I have to think about this ...	Bernhard Voelker <berny>
Sat 07 Jul 2018 07:39:49 PM UTC, original submission: $ touch file $ ln -s nowhere broken $ ln -s file/nowhere notdir $ find -L . ./file ./broken find: ‘./notdir’: Not a directory ./notdir So we get an error message if a link is broken in one way but not another. Worse, $ find -L broken broken $ find -L notdir find: ‘notdir’: Not a directory So at the top level, notdir is not even printed. Same with -H.	Tavian Barnes <tavianator>

(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 jay (Updated the item)

-email is unavailable- added by berny (Posted a comment)

-email is unavailable- added by tavianator (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.

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
2024-05-19	jay	Assigned to	None		berny

findutils - Bugs: bug #54263, find -L treats ENOENT and ENOTDIR...

bug #54263: find -L treats ENOENT and ENOTDIR differently

<a href="#postcomment">Post a Comment</a>

<a href="#discussion">Discussion</a>

<a href="#attached">Attached Files</a>

<a href="#dependencies">Dependencies</a>

<a href="#cc">Mail Notification Carbon-Copy List</a>

<a href="#votes">Votes</a>

<a href="#history">History</a>