Ok. The core of this problem is clearly defined now: a FOR-set that remain static while the FOR is executed vs. a FOR-set that change because a command in DO part. Note that this difference is NOT necessarily related to FOR vs. FOR /F; for example:
Code: Select all
for /F "delims=" %%a in (thefile.txt) do (
echo %%a >> thefile.txt
)
I think previous FOR may read lines created by itself if the file size before the FOR is larger than the buffer used to read the file. The possible explanations of FOR behavior may give us the way to understand it and plan methods to avoid the problem. However, I want to emphasize a particular point of this problem.
Liviu wrote:Don't know that I'd call it a "bug", since there is no "expected" behavior mandated or guaranteed in any docs I've seen about what "should" happen once the code in the loop modifies the fileset the loop itself works on...
...but then one would have to define what the "expected outcome" would be, first.
Liviu
I think the "expected behavior" should be
the same in any case. In the original example I used to start this topic, if FOR-command would check that this condition not happen, then "Poster 1.jpg" file would not be renamed to "Poster 3.jpg". On the other hand, if FOR-command does NOT have this checking, then it would enter into an endless rename loop ("Poster 2" to "Poster 4", "Poster 3" to "Poster 5", etc). Why FOR-command rename an already renamed file
just one time? This is what I call BUG!
Antonio