New version uploaded that fix a file renaming bug, or better, it fix filenames now better (and to do, it works for some milliseconds slower)
Now files that already had in subfolders something like "file (1).ext" will not renamed to "file (1)(1).ext" anymore, they will get a correct "free" number inside the last ().
On the other hand, if you having a file like "file (2023).ext", that would be first of all tried to be renamed to "file.ext" and if that is not free it start with "(1)" etc.
So some files that having at last position a number in () might get renamed incorrect.

I would like to hear your opinions about if I should for example
- pop up a [yes/no] dialog to let user decide what to do (what can be a lot, depending on number of files with (number) at end of filename)
- add .ini feature to include it as option (for automated but configurable per session runnings)
- let app like it now is and risk a loose of, for example an added year that was written in ()

If you are talking about Windows, maby Autoruns help you to identify the bad guy?

Thanks for your sweet words, how nice of you  :-*
BTW my logic error on those 2 other pretty similar tools that I've released lately I just found out by creating this, so thanks for inspiration again  :Thmbsup:

I've updated my version for even more faster speed by not collecting files from root folder anymore.
Also changed my internal workflow to do a two-in-one thing, right after moving files the folder will be deleted.
(in my first release everything was splitted up into folders and files that was processed)
I guess I've reached now the maximum whats possible with pure Windows-API technology and logic.
Added also version information, now I am at v0.0.0.3

Micro-updated the final dialog, v0.0.0.4