Update of bug #67330 (group findutils):
Open/Closed: Open => Closed
_______________________________________________________
Follow-up Comment #4:
For further clarification, eventually the following example
helps.
mkdir test
cd test
# Test 1: first traverse 'b', then 'a'.
rm -rf a b; mkdir a b && touch a/file{1..100000}
find -D exec b a -name 'file*' -exec mv -t $PWD/b '{}' +
# Test 2: first traverse 'a', then 'b'.
rm -rf a b; mkdir a b && touch a/file{1..100000}
find -D exec a b -name 'file*' -exec mv -t $PWD/b '{}' +
In case 1, find(1) does not find a match in directory 'b',
and continues with 'a'. This succeeds.
In case 2, find(1) first processes all files in 'a' and
therefore moves them to 'b', and then processes 'b', and
thus finding all the just-moved files again.
Here mv(1) complains that the source and target - i.e.,
within directory 'b' - is the same.
Please note that depending on using -exec or -execdir and
the number of files to move, find(1) has to use multiple
mv(1) invocations or not.
Therefore the effect does e.g. not happen with -exec and
only 10 files regardless of the search order 'a b' vs. 'b a',
because find(1) will only fork one mv(1) after processing both.
Therefore, as this is not a bug, and there's nothing we could
do about it (not even imcproving the docs I think), I'm hereby
closing the issue.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67330>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
