Bug found in auto-rename

[Fla$her]

name (001)(2).txt

Here should be a space: name (001)_(2).txt

[Galizza]

Here should be a space: name (001)_(2).txt

I agree

[sa16]

2Fla$her
2Galizza
If AutoRenameMode=2, there should be no space.

[ghisler(Author)]

So if I understand you correctly, the existing number in braced should still be increased, except if
1. The braces are NOT at the end, or
2. The number in the braces has leading zeroes
I think this is a reasonable compromise which prevents names like name (2)(2)(2).ext

[Galizza]

 

So if I understand you correctly, the existing number in braced should still be increased, except if
1. The braces are NOT at the end

 
This doesn't prevent the possibility of serious errors, such as those that can arise from names Auto renamed in the following way:


Original name: "Sales Report (2016).txt"
Auto-renamed as: "Sales Report (2017).txt"


I think there should be a new option in AutoRenameMode= for users who want to avoid any possible errors, even at the cost of file names appearing in the format.

name (2)(2)(2)(2).ext

 

[ghisler(Author)]

That's a good idea, I will let the user add 4 to always ignore an existing number in the original name.

[Galizza]

That's a good idea, I will let the user add 4 to always ignore an existing number in the original name.

Thanks

[white]

So if I understand you correctly, the existing number in braced should still be increased, except if
1. The braces are NOT at the end, or
..

To be clear: the end of the filename without extension.

And when increasing an existing number, maintain the original format. So when increasing a number with no leading space before the bracket, no leading space should be used with the new number as well. (And if increasing a number with leading zeros were to be supported as well, the new number should not have less digits.)

[sa16]

Maybe it makes sense to take auto-renaming to Multi-Rename Tool (MRT) as a sample? Or is there a bug there too?

[ghisler(Author)]

To be clear: the end of the filename without extension.

Since names can have multiple dots, there is no easy way to distinguish between name and extension, e.g. when renaming directories:
Photos.2024.New York (1)
Therefore I prefer not to make any such limitations.

Maybe it makes sense to take auto-renaming to Multi-Rename Tool (MRT) as a sample? Or is there a bug there too?

The MRT just always appends a number and doesn't analyze the original names. That's what adding 4 to AutoRenameMode will do. I don't want to make this the default, though, it would be too radically different from how it works now.

[AntonyD]

2ghisler(Author)
And why did you mix both files and directories in your answer?
These are different entities and they have different rules for attaching an auto-naming counter.
For directories, this is done simply at the very end of their current full names
For files - strictly before the last dot in their full name.
Because windows cannot contain files with a dot, but without an extension, then THERE is a
very pretty easy way to distinguish between name and extension:
If there is a dot - and it doesn't matter how many there are - the last one will be the border
where the name ends and the extension begins.
If the file has NO extension (without a dot), then the rule above applies for directories.

[sa16]

The MRT just always appends a number and doesn't analyze the original names. That's what adding 4 to AutoRenameMode will do.

Excellent: if AutoRenameMode >3, then auto-renaming will be performed when copying, as in MRT (according to the rules of the current TC help).

[white]

To be clear: the end of the filename without extension.

Since names can have multiple dots, there is no easy way to distinguish between name and extension, e.g. when renaming directories:
Photos.2024.New York (1)
Therefore I prefer not to make any such limitations.

Right, makes sense.

I’ve tested how Windows 11 handles pressing Ctrl+C followed by repeated Ctrl+V on a filename that already includes a number in parentheses. I also examined how Total Commander behaves when copying a file named "text.txt" to a filename that already has a number in parentheses while using its auto-rename feature. Here are my findings:

Remarks	Destination file	Results Windows	Results TC
Number in the extension   (Windows doesn't increase the current number)	test.c(3)	test - Copy.c(3)   test - Copy.c(2)   test - Copy.c(4)	test.c (4)   test.c (5)   test.c (6)
Number and a space in the extension   (Windows assumes no extension)	test.c (3)	test.c (3) - Copy   test.c (4) - Copy   test.c (5) - Copy	test.c (4)   test.c (5)   test.c (6)
Leading zeros	test (003).txt	test (003) - Copy.txt   test (4) - Copy.txt   test (5) - Copy.txt	test (4).txt   test (5).txt   test (6).txt
No leading spaces before the opening bracket   (TC adds a space)	test(3).txt	test(3) - Copy.txt   test(4) - Copy.txt   test(5) - Copy.txt	test (4).txt   test (5).txt   test (6).txt
Multiple numbers   (Windows uses first number)   (TC uses last number)	test (3) (3).txt	test (3) (3) - Copy.txt   test (4) (3) - Copy.txt   test (5) (3) - Copy.txt	test (3) (4).txt   test (3) (5).txt   test (3) (6).txt