findutils - Patches: patch #9705, make ftsfind honour the...
You are not allowed to post comments on this tracker with your current authentication level.
patch #9705: make ftsfind honour the -ignore_readdir_race option
Submitter: | Gajendran Kanapathipillai <gajendrank> | ||
Submitted: | Mon 15 Oct 2018 03:25:13 PM UTC | ||
Votes: | 10 | ||
Category: | find bugfix | Priority: | 5 - Normal |
Status: | None | Privacy: | Public |
Assigned to: | berny | Originator Name: | |
Open/Closed: | Open | Release: | None |
Fixed Release: | None |
Mon 15 Oct 2018 10:00:12 PM UTC, comment #5: |
Bernhard Voelker <berny>![]() ![]() |
Mon 15 Oct 2018 07:54:40 PM UTC, comment #4: That was my finding too. This only happens on certain installations and not others. On a system where a physical parition (e.g. /dev/sda2) mounted with xfs had the same output as you've shown below.
Linux 4.4.109-1.el7.elrepo.x86_64 #1 SMP Tue Jan 2 17:24:53 EST 2018 x86_64 x86_64 x86_64 GNU/Linux
/dev/mapper/vg_root-lv_root on / type xfs (rw,relatime,seclabel,attr2,inode32,noquota)
|
Gajendran Kanapathipillai <gajendrank> |
Mon 15 Oct 2018 06:39:48 PM UTC, comment #3: [re-opeing the issue]
|
Bernhard Voelker <berny>![]() ![]() |
Mon 15 Oct 2018 04:58:27 PM UTC, comment #2: Actually, with the ftsfind, the test never gets to the code where earlier patch (0afb2efad) is fixing the issue. Instead, the ftsfind errors early and sets the errno to "1". Which causes the "-ignore_readdir_race -delete" combination to still fail and return error.
|
Gajendran Kanapathipillai <gajendrank> |
Mon 15 Oct 2018 03:44:39 PM UTC, comment #1: That patch has already been applied 2018-03-14:
|
Bernhard Voelker <berny>![]() ![]() |
Mon 15 Oct 2018 03:25:13 PM UTC, original submission:
In the ftsfind, the ignore_readdir_race is not considered when the file goes missing. Please refer to the following fix for the issue and how this patch was tested:
|
Gajendran Kanapathipillai <gajendrank> |
Depends on the following items: None found
Items that depend on this one: None found
There are 10 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.
Follow 8 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2018-10-22 | antigoon2 | Carbon-Copy | - | ![]() |
Added antigoon2 |
2018-10-15 | berny | Status | Done | ![]() |
None |
2018-10-15 | berny | Open/Closed | Closed | ![]() |
Open |
2018-10-15 | berny | Status | None | ![]() |
Done |
Assigned to | None | ![]() |
berny | ||
Open/Closed | Open | ![]() |
Closed | ||
2018-10-15 | jansmets | Carbon-Copy | - | ![]() |
Added jansmets |
2018-10-15 | gajendrank | Attached File | - | ![]() |
Added 0001-find-make-ftsfind-honour-the-ignore_readdir_race-opt.patch, #45201 |
I couldn't reproduce with that test case on XFS, but I played a bit
with trying to create races.
It seems there are more race conditions which -ignore_readdir_race
should catch. The following creates 'tmp/d' alternatively as a
directory and a regular file:
$ while mkdir -p tmp tmp/d && rm -fr tmp/d && touch tmp/d && rm -f tmp/d ; do : ; done
Now, in a second terminal, the following command should ideally run without errors:
$ while : ; do ~/findutils/find/find -D search -ignore_readdir_race -delete || break; done
It turns out, that find terminates at least when it gets an error
from newstatat(), and from open().
Needs some more investigation ...