Suggestion: Automated intermediate step for multi-rename

[JohnFredC]

Some renaming operations require an intermediate step to resolve naming conflicts.

Perhaps there could be an optional TC behavior that resolves (multi-)renaming conflicts "behind the scenes"?

If TC could perform the intermediate step for us (with notification and user cancellation possible, of course), then the multi-rename tool could save me an additional renaming step.

A valid concern would be if the "automated" intermediate step should fail for some reason and the original names lost. But a rational approach to constructing the temporary names used as intermediates (ie prefixing a random value to each original name, for instance, with the original filename preserved as a suffix) could prevent disaster, even if TC itself should fail to detect a problem.

An efficiency would be to perform the intermediate step only on the conflicting files.

One issue with this approach has to do with renaming files with filenames whose original length approaches the operating system limit for filenames.

[nsp]

Support +1 !

But instead of speaking of an intermediate renaming step, we could just speak of a definition step as renaming should occur only once per file...

Let say
A0 -filter 1-> B0 -filter 2-> C0 should be gathered as A0 become C0 ...

Have a complete Renaming scheme with conflict management (Verify if more than one Ci is produced, if Ci correspond to existing file (not renamed), reorder renaming to have no colison on renamed file, verify swapped name and build intermediate step with guid name...

we can have an 2 additional button with "next/previous" definition. the first step "lock source file"... the renaming listing with intermediate definition or not... And the DO RENAME !

[TLis]

See, for example, the thread http://www.ghisler.ch/board/viewtopic.php?t=15477&highlight=. There are tools (Siren), that can help, but of course, I would like to see a native name clash resolving facility in MRT

[ghisler(Author)]

There is the arrow button in the footer of the MRT to load the new names into the MRT for the next rename step.

[JohnFredC]

With all due respect, I know about the arrow button and use it. However, the way the multi-rename tool is currently implemented, I myself have to determine an adequate intermediate renaming step when naming conflicts are detected.

But my philosophy (both as a user and as a developer) is that if the computer (that is: TC) can (ie. could possibly, if programmed to) do a particular task, why shouldn't it?

Though the arrow button is a portrayed as a convenience to the user (and it surely is, considering the current state of the multi-rename tool), in fact it just compensates for an as yet unimplemented part of the automated file renaming task. I should not have to pause, scratch my head, and ponder an intermediate step that aids the renaming schema I have decided on. If naming conflicts can be detected automatically, then they can also be accounted for, automatically.

Perhaps the implementation is difficult. Or perhaps there is a question whether the value to the TC user public "at large" balances the effort and resources needed to implement such a function.

The fact remains, however, that such an implementation is possible, and may have benefit.