[Bug TC6.01] rename AAA.AAA.12345 into B.B.* gives B.B.345

[white]

BTW: There are other programs that do not handle file names with multiple periods correctly. It seems quite a common error to search the first period instead of the last one.

To search the first period is probably the way it was programmed before long file names. Maybe they forgot to change this when they added long file name support.

Or maybe it means they simply do not support file names with multiple dots.

Maybe they didn't care.

Or maybe file naming conventions are not very clear. Take these naming conventions at msdn for example. It states:

Use any character in the current code page for a name, except characters in the range 0 through 31 or any character explicitly disallowed by the file system. A name can contain characters in the extended character set (128?255). However, it cannot contain the following reserved characters: < > : " / \ |

So periods are allowed in the file name. But it also states:

Use a period (.) to separate the base file name from the extension in a directory name or file name

This is kinda confusing. Would be a lot clearer if they had said: "Use the last period (.) in a directory name or file name to separate the base file name from the extension"
Probably this text has its origin in the 8.3 file names era.

[StatusQuo]

Take these naming conventions at msdn for example.

The document has moved and can now be found here: naming conventions at msdn.
Unfortunately it still seems to be unchanged.

[StatusQuo]

(This "bug" still exists in TC7 rc2.)

A word to the behaviour of renaming...

Suppose you have the file "file.name.ext", which is the only file in a folder.
In DOS (Wind*ws command line): "REN *.* [target_name]" is used.
In TC: <Shift-F6> (inplace-rename) is used.

Results with different target file names:

Code: Select all

12.34.56.78.90.1234.*

will lead to
REN: 12.34.56.78.90.1234
TC7: 12.34.56.78.90.1234

Code: Select all

*.34.56.78.90.123.*

will lead to
REN: file.name.34.56.78.90.1234
TC7: file.name.34.56.78.90.1234


But:

Code: Select all

12.*.56.78.90.1234.*

will lead to
REN: 12.name.56.78.90.1234
TC7: 12.ext.56.78.90.1234

Code: Select all

12.34.*.78.90.1234.*

will lead to
REN: 12.34.ext.78.90.1234
TC7: 12.34.78.90.1234

So:
- MS's REN command is inconsistent when using "*" before the first "." ("name" appears both in the first part together with the leading rest and in the second part).
- TC's inplace rename is inconsistent separating the source file name into "name" and "extension", without treating the target file name the same way (using MS's replace-strategy and putting the source "extension" in target's second "part").

- MS (in REN command while parsing the name) seems to separate parts by dots as delimiters and then exchanges those parts from source name in target name.
- TC does a mix of MS's method and locating/defining the "extension".

I strongly think that something should be fixed here.
Bug or not?

[ghisler(Author)]

There is no logical way to do it, there are always situations where the one or the other way would be mor logical, sorry.