DosTips.com

The issue is described in this stackoverflow answer by debenham:

The simple FOR command with wildcards begins iterating files before it finishes reading the entire directory. It buffers a block of files and iterates them, then picks up where it left off. When you rename a file, the renamed file may sort later in the list, and be picked up in a later block of files. Hence the double renaming.

In my opinion this behaviour is due to compatibility reasons of the FCB structure of CP/M, but I'm not sure.
Does anybody know an other reason and has a link to a technical description?

Thanks for reading

The FCB should be not used for accessing file meta data (name, size, ...).
it should be used only if you want to access files (open it for reading/writing).

For speeding up the access of block oriented external data (such as file meta data) B-Trees, B+-Trees, or B* Trees are in use,
which should be the cause of the observed behaviour:
https://en.wikipedia.org/wiki/B-tree
https://en.wikipedia.org/wiki/B%2B_tree


penpen

Thanks, I assume, you are right. This is probably an issue of the FAT system compatibility, namely the file entries and the for loop pointer to this entries. The for loop not always creates an additional file and sometimes it creates three or more files. It depends on whether the new file entry is added before or after the for loop pointer.

Thanks for your help!

Endoro wrote:This is probably an issue of the FAT system compatibility

Not in this case.
Using B-Trees (of any type) significantly reduces the amount of external medium read+write operations when accessing block oriented external data.
So B-Trees are used in all filesystems (and for example in nearly every database) since the development of B-trees, because any disk is an external
medium, and (up to now) all filesystems are block oriented; typically:
One (or more) block(s) containing the file metadata, and multiple blocks containing the data;
for small files metadata and data may be stored in just one single block.


penpen