Total Commander

Issue:
I often rename a very large number of files/directories so as to normalize the naming convention. Unfortunately, this sometimes results in a name collision.

The current behavior is to stop at the first collision and note it to be resolved. The next rename attempt finds the second collision and stops. The next rename collision finds the next collision, etc., one at a stinkin' time! If there are multiple collisions, it becomes a Royal Pain In The Tush.

Suggestion: (This can become an option setting if desired)
Allow name collisions to be automatically resolved by appending a number to the colliding file/directory name in the same manner that Windows does it.

Viz.:
colliding filename
colliding filename (2)
colliding filename (3)
next collision
next collision (2)
etc. . . . .

This would be SO APPRECIATED you would not believe it!

Thanks again for a wonderful program.
[/i]

 
Auto rename on file name collision / Auto fix name collisions on duplicate name

[face=timesnewroman]colliding filename.ext
colliding filename (2).ext
colliding filename (3).ext[/face]



Support++


Please Mr. Ghisler, consider for TC 9.0




 

It's already implemented in TC, under "More options" -> "Auto-rename copied"
Image: http://i.imgur.com/VPxraIm.png
It works exacly how you want it, you select many files, rename, enter abc.* in rename pattern, and on first conflict you just select that option and all files will be auto renamed to abc.ext, abc(2).ext, abc(3).ext ...

2kapela86

jharris1993 wrote:Issue:
I often rename a very large number of files/directories so as to normalize the naming convention. Unfortunately, this sometimes results in a name collision.

The case in point is Multi Rename Tool (MRT), not COPY files ...

It's currently not possible in MRT. Why? It would require TC to determine all the names for the preview BEFORE displaying a single line, because the names would depend on each other. This can be terribly slow when using plugins for the names,

Maybe you can ask user and rename files on the fly w/o showing such things in preview? I.e. if TC sees that such name exists, it asks user to overwrite/autorename, and then (if user decides to autorename) just autorenames all repeating names.

Interesting idea! Maybe I could show something like this in the preview:
newname?.txt
newname?.txt

Where ? stands in the location of the placeholder. What do you think?

But there is still a problem: Search+Replace is applied AFTER the name placeholders. So for example
New name: [N][x (d)]
Seach for: 3
Replace with: 2

If names are generated like this:
newname.txt
newname (2).txt
newname (3).txt

Search+Replace would still generate duplicates:
newname.txt
newname (2).txt
newname (2).txt

So it would be best to apply autorenames after search+replace, but then the name could be mangled up completely by regex etc.

I don't want to see the result in the list.
I don't want to see that conflicts on creation time.
That would be fine too, but makes no sense for longer list of files.
If you want to do that, fine too.



I just want an option to automatically add a suffix to duplicated file names on renaming time.

Perhaps this would be a way:

Isn't it, that TC knows after pressing the [Rename] button
which file can't be renamed due to name collision?

If that problem occur, instead of just saying "I can not",

add something like that pseudo code to your renaming function like:

Do rename... filename.ext
IF (ERROR)
  IF (PreventDubs=1)
    While ( filename (num).ext exist )
          num++
    End While
    Do rename... filename (3).ext
  End IF
ELSE
    Continue
End IF
MsgBox "Added suffix to 8 files automatically due to same name error"


That way we can rename without errors and check the files afterwards, if wanted, by browsing the folder.


.

I don't think too that collisions should be marked somehow in MRT preview list, it should just show the names that user wants to get during rename.

But I think that TC doesn't know which files can't be renamed when you press Rename button. While it renames, external application may change something in these folders e.g. But it would be enough for TC to behave just like while usual copy/move: ask questions when they occur or postpone them and ask later...

OK, maybe a checkbox "Add suffix on collision" would be better than a placeholder, but then the user couldn't configure that suffix. I would just use (2) (3) etc.

Yes, do not allow controlling suffix, just use a standard one.

You can simply replace 'Error, could not rename the files shown in bold!' messagebox with a one asking to auto-rename, so no checkboxes will be required. I think it should be different from existing duplicates warning because it is a run-time one.
However a checkbox in MRT dialog may be useful too, just to prevent additional question.

MVV wrote:

Code: Select all

rename -> 'dups! continue?' YES -> problems? YES -> 'dups! auto-rename?' NO -> 'could not rename' -> end
rename -> 'dups! continue?' YES -> problems? YES -> 'dups! auto-rename?' YES -> auto-rename -> problems? NO -> end
rename -> 'dups! continue?' YES -> problems? YES -> 'dups! auto-rename?' YES -> auto-rename -> problems? YES -> 'could not rename' -> end

I don't get your "Flowchart".
You mean sth. like this?
What could happen between agreement for "continue on duplicates" question and the check for auto-rename?
(what kind of "problems"?)
What is there to continue if you don't know whether you should auto-rename or not?

In my concept TC will use auto-rename when you agree to continue, and cancels otherwise.
And a check box in MRT will trigger if TC should ask for continuation at all.

milo1012 wrote:I don't get your "Flowchart".
You mean sth. like this?

If I've got your "flowchart" right, yes, something like this.

What could happen between agreement for "continue on duplicates" question and the check for auto-rename?
(what kind of "problems"?)

Some other program may add files to directory so new duplicates appear.

And a check box in MRT will trigger if TC should ask for continuation at all.

I think some people will want an option to auto-rename always, so third option may be useful (autorename: never, always, ask). Personally I would use 'ask' case.

I think regular TC replace dialog would be nice here, it already has all required auto-rename and other features.

MVV wrote:Some other program may add files to directory so new duplicates appear.

That's the point I was talking about and which I don't get.
TC tries to rename files one by one (it processes a rename queue), and notes an error if one rename op fails.
I don't see why you would distinguish between duplicates resulting from your MRT settings, and duplicates arising from external programs.
You just process every file in the queue, and react on errors.
So this means you just have to distinguish between two kind of errors: a file from the list not being accessible (any more), and a new name not able to be created due to duplicate names.
For the latter, depending on the auto-rename option(s), ask the user or do an automatic rename.
For the former you just collect the errors and inform the user at the end, just like it is now.
If an auto-rename fails, you just increment the number until it doesn't fail any more, again by either asking the user or do it automatically.

MVV wrote:I think some people will want an option to auto-rename always, so third option may be useful (autorename: never, always, ask). Personally I would use 'ask' case.

Agreed. (maybe a tri-state check box is enough for this)

MVV wrote:If I've got your "flowchart" right...

Well, it's a more or less standardized Nassi–Shneiderman diagram (structogram)

I don't see why you would distinguish between duplicates resulting from your MRT settings, and duplicates arising from external programs.

It is easy: 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 run-time dups may not (so auto-rename is the only available option - though standard overwrite dialog could provide more options).

Well, it's a more or less standardized Nassi–Shneiderman diagram (structogram)

... seen by me for the very first time.