MRT MultiRenameTool: search/replace fails for subdirs after feed to listbox

[StatusQuo]

Trying to multi-rename directories from search results (feed to listbox) fails, because after renaming upper levels the lower levels are no longer accessible - multiple runs of both search and rename need to be started by the user for each directory level.

To reproduce:
Have a directory structure like D:\MRT\test one\test two\test three (each containing a space)
and directories sorted alphabetically (Options > Display > Sorting directories set to "Always by name")

• cd to D:\, mark the base test dir (D:\MRT)
• press Alt+F7 (cm_SearchFor) (this option is activated by TC: [X] Only search in selected directories/files)
• enter " " (a space) in "Search for" field
• press "Start search" button => all three test folders are found
• press "Feed to listbox" button
• mark all found entries and press Ctrl+M (starts Multi Rename Tool)
• enter in Search for: " " (space, without quotation marks)
• enter in Replace with: "_" (underscore, without quotation marks)
• press Start

=> TC only renames the first entry/directory level, then shows dialog "Error, could not rename the files shown in bold".
On a second run it would rename the second level and show the error for the third level, and so on.
For larger directory structures a lot of runs would be needed to finish the task.

If MRT would do renaming of child folders before their parents it would not fail on sub-directories.

Manual workaround (this way it works):
Turn off before starting MRT: Options > Display > Sorting directories is set to "Always by name",
then in MRT sort by name in negative order before pressing Start.
Turn on again after leaving MRT: Options > Display > Sorting directories is set to "Always by name",

Suggestion:
(Internally) always sort directories in MRT by name/path in negative order - this should avoid subdir conflicts regardless of displayed sorting.

[ghisler(Author)]

This is a well-known limitation which has been known for a long time. Currently it's not planned to change the order in which files are renamed, especially not renaming them in negative order by default. Why? This would collide with functions like auto-rename on collision, because the files would get renamed in reverse order. Maybe it could be done as an option, but the dialog is already quite overloaded, and translators have been contacted.