That's obvious. And this check should stay as it was, IMO.MVV wrote:MRT setting dups may be predicted before starting overall rename operation (just like current TC checks for duplicates in resulting names and hints that something may be set wrong)
But I meant duplicates resulting from TC's own rename procedure, where TC can't distinguish in advance that conflicts may arise.
Simple example: having files like
1.txt
2.txt
3.txt
and now trying to rename them in reverse order with [N]
Result: TC tries, but fails of course, due to a lack of "predicting" logic.