Bug found in auto-rename

[ghisler(Author)]

Confirmed, I will cut off the extension before looking for the last braces.

[AntonyD]

2white
In the first row "Number in the extension" in the columns "Results TC - TC 11.51rc1 - Idem, autorename=7", the space somehow very strangely "jumps". Sometimes it's there in one place, sometimes it's not. And in general, a space is not expected in this test-case. After all, even the test in this row seems to be directed at this feature. Are there definitely no mistakes in what is written in the table - what come out in fact?

[white]

Are there definitely no mistakes in what is written in the table - what come out in fact?

I think there are no mistakes. Test it yourself

[AntonyD]

test.c(3)
fresh INI = Indeed I Will get "test.c (4)". And I do not understand why this is not treated as an old-fashion bug?

Option AutoRenameMode=3 (def.value) always should process only the NAMES of any files.
So WHY in this test filename this option affected the change of the file's extension?
And yep - the change did occur even partially! The selected default constants 3=1+2 seem to mean that the counter
of new files will be added in parentheses with a space and will start from two. So in our example (even if we set
aside the fact of incorrect change of the extension), we should have gotten: "test.c(3) (2)"
If we somehow allow ourselves to change extensions instead of file names of course......

[ghisler(Author)]

test.c(3)
fresh INI = Indeed I Will get "test.c (4)". And I do not understand why this is not treated as an old-fashion bug?

By default, numbers without leading zeroes will always be increased when auto-renaming. Use add 4 to
AutoRenameMode to prevent that from happening.

[AntonyD]

2ghisler(Author)
My question was about absolutely another thing.
Why your code is touching EXTENSION?
If when we talk about auto-renaming feature - we focus ONLY on the file names!

test.c(3)
file name: "test"
extension: "c(3)"

so if by default AutoRenameMode=3 means 3=1+2 what means what the counter of new files
will be added in parentheses with a space and will start from two FOR THE FILENAME!
So why extension in a fact will be changed?

[ghisler(Author)]

Why handle numbers in the extension differently from numbers in the name part?
Some users may want to give the backup files a different extension so they don't accidentally open them with Enter. In the above case, Enter on test.c would open some kind of development editor (which can be quite slow), while Enter on test.c(3) would just show the open with dialog. If I change this now, I'm sure I will get protests from other users who rely on the current behavior.

[Horst.Epp]

...
I'm sure I will get protests from other users who rely on the current behavior.

I'm sure the majority of users will not like that their handcrafted extensions are changed
just because they do a name change.
Let the exceptions from this handled by the user themselves.

[ghisler(Author)]

But the numbers are already in the extension, with braces! This is very unusual to do this and then not use it for auto-renaming...

[white]

Perhaps TC could check if the extension has a default verb (or any verb?) assigned to it. If not, use an existing count in the extension.
Or phrased the other way around: don't change the extension if the extension has a default verb (or any verb) assigned to it.

[AntonyD]

2ghisler(Author)

But the numbers are already in the extension, with braces!

Should that have any bearing on the fact that we want a new copy of the file with a changed NAMe! of a file?
NAME! if the extension is changed - in 99% of cases there must be an extreeeeeeemely good reason for it.
And here your auto-reNAMeing algorithm - has an effect on the extension of this file! for nothing.
Although the verb of the action being applied clearly indicates WHAT exactly is to change.

[ghisler(Author)]

Have you tried autorename=4 or autorename=7 with RC2? It should add a new number to the name and then only increase that number.

[AntonyD]

Yep, just now and looks like 4 mode is perfect now.

[white]

Test results indicates that it works as designed now:

Remarks	Destination file	Results Windows	Results TC	* TC 11.51rc2	* autorenamemode=7
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)	test.c (4)   test.c (5)   test.c (6)	test (2).c(3)   test (3).c(3)   test (4).c(3)
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)	test.c (4)   test.c (5)   test.c (6)	test (2).c (3)   test (3).c (3)   test (4).c (3)
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	test (003) (2).txt   test (003) (3).txt   test (003) (4).txt	test (003) (2).txt   test (003) (3).txt   test (003) (4).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	test (4).txt   test (5).txt   test (6).txt	test(3) (2).txt   test(3) (3).txt   test(3) (4).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	test (3) (4).txt   test (3) (5).txt   test (3) (6).txt	test (3) (3) (2).txt   test (3) (3) (3).txt   test (3) (3) (4).txt
Number not at the end of filename	test (3)a.txt	test (3)a - Copy.txt   test (4)a - Copy.txt   test (5)a - Copy.txt	test (4)a.txt   test (5)a.txt   test (6)a.txt	test (3)a (2).txt   test (3)a (3).txt   test (3)a (4).txt	test (3)a (2).txt   test (3)a (3).txt   test (3)a (4).txt

[ghisler(Author)]

Great, thanks for testing!

Moderator message from: ghisler(Author) » 2025-05-20, 15:53 UTC

Moved to fixed bugs