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

[white]

Edited: Changed the Subject so it demonstrates the bug more clearly. Original Subject was:
[Bug TC6.01] rename A.123456 into B.B.* results in B.B.3456

rename A.123456 into B..* results in B..23456
rename A.123456 into B.B.* results in B.B.3456
rename A.123456 into B.BB.* results in B.BB.456
rename A.123456 into B.BBB.* results in B.BBB.56
rename A.123456 into B.BBBB.* results in B.BBBB.6
rename A.123456 into B.BBBBB.* results in B.BBBBB
rename A.123456 into B.BBBBBB.* results in B.BBBBBB

same goes for the copy command.

[Rou]

I had the exact same problem in version 5. Cant remember which revision though.

[karlchen]

Hi, folks.

Maybe I am a bit slow in the uptaking, but telling from the examples given, I do not see what should be wrong and where is the bug?
The results may not be what you expect them to be, but as far as I can tell from the examples, I cannot see a programme bug.
I think TC does exactly what you tell it to do, but what you tell it to do is not what you really want.
Could you please explain what exactly the correct results should be?

Kind regards,
Karl

[white]

The file name extension should not be different from the file name extension of the original file. It should not matter whether or not the new file name (the part without extension) contains a dot or not.

The correct results should be the same as the ones you get when you do the rename operations in a DOS box.

[karlchen]

@white

From what I tested under TC (renaming) I can confirm your results for TC.

I do, however, doubt your statement about the results in a DOS-box.
At least I got quite different results there.
Here is what I did using CMD.EXE, 4NT.EXE and COMMAND.COM under WinXP, all three giving the same results:
Before each rename command, I (re-)created the file A.123456
ren A.123456 B..* results in B
ren A.123456 B.B.* results in B.B
ren A.123456 B.BB.* results in B.BB
ren A.123456 B.BBB.* results in B.BBB
ren A.123456 B.BBBB.* results in B.BBBB
ren A.123456 B.BBBBB.* results in B.BBBBB
ren A.123456 B.BBBBBB.* results in B.BBBBBB

Did you really test the rename commands in a DOS-box?

Back to TC:
From my point of view, TC acts differently from a DOS-box, but acts in a more clever and a more logical way:
It looks at your rename pattern, e.g. B.BB.*. It sees the first 4 letters "B.BB" are fixed, the rest is wildcard "*".
So it takes the source filename, replaces letter 1,2,3,4 by "B.BB" and keeps the rest of the original filename.
It cannot take into account your consideration about your extension ".123456", because all your renaming patterns have got double extensions
(..*, .B.*, .BB.*, .BBB.* etc pp)

As I demonstrated, TC and CMD.EXE/4NT.EXE/COMMAND.COM all give different results for your renaming commands.
None of them acts in an incorrect way.
They simply interpret the intention in different ways.
And that is the point:
It is a question of definition how your renaming command should be interpreted, because in fact it is ambiguous.

The best chance of getting the results that you expect is using TC's Multirename Tool for tricky renaming procedures like yours.
So try Ctrl+M to launch Multirename and try it out.

Kind regards,
Karl

[white]

Here is what I did using CMD.EXE, 4NT.EXE and COMMAND.COM under WinXP, all three giving the same results:
Before each rename command, I (re-)created the file A.123456
ren A.123456 B..* results in B
ren A.123456 B.B.* results in B.B
ren A.123456 B.BB.* results in B.BB
ren A.123456 B.BBB.* results in B.BBB
ren A.123456 B.BBBB.* results in B.BBBB
ren A.123456 B.BBBBB.* results in B.BBBBB
ren A.123456 B.BBBBBB.* results in B.BBBBBB

Interesting. Maybe that is a bug in those programs
And what happens when you execute the line below?
ren A.A.123456 B.B.*

Did you really test the rename commands in a DOS-box?

Yes, but I use Windows 98. My results are:
ren A.123456 B..* results in B..123456
ren A.123456 B.B.* results in B.B.123456
ren A.123456 B.BB.* results in B.BB.123456
ren A.123456 B.BBB.* results in B.BBB.123456
ren A.123456 B.BBBB.* results in B.BBBB.123456
ren A.123456 B.BBBBB.* results in B.BBBBB.123456
ren A.123456 B.BBBBBB.* results in B.BBBBBB.123456

From my point of view, TC acts differently from a DOS-box, but acts in a more clever and a more logical way:
It looks at your rename pattern, e.g. B.BB.*. It sees the first 4 letters "B.BB" are fixed, the rest is wildcard "*".

You mean: It sees the first 5 letters "B.BB." are fixed, the rest is wildcard "*".
So following your point of view renaming A.123456 into BB.* would result into BB.23456 (which it does not)
And what do you think about TC renaming AAAAAAAA.123456 into B.B.* results in B.B.3456?

It cannot take into account your consideration about your extension ".123456", because all your renaming patterns have got double extensions (..*, .B.*, .BB.*, .BBB.* etc pp)

I have never heard of double extensions. By design the last period separates name and extension.

[karlchen]

@White
The fact that command.com under Win98 gives you the results that you expect make me understand why you consider TC's behaviour buggy.

The only person who could explain why TC behaves the way it does is Christian Ghisler. So maybe we are lucky and he reads this thread and takes the pain of dropping us some lines.

The fact that dos-boxes under Win98 and WinXP behave differently, shows that even Microsoft does not interpret your command in a consistent way.

Did you try to get the correct results using TC's Multirename tool, too?
Successfully or without success?

Kind regards,
Karl

[white]

In TC do:
rename AAAA.AAAA.123456789 into B.B.* results in B.B.3456789
rename AAAA.AAAA.123456789 into B.B.B* results in B.B.B6789
rename AAAA.AAAA.123456789 into B.B.B.B.* results in B.B.B.B.789
rename AAAA.AAAA.123456789 into B.B.B.B.B* results in B.B.B.B.B89

What TC does is:
In the original file name the last period separates the file name from the extension.
And in the mask of the new file name the first period separates the file name from the extension.
I fail to see how TC acts in a more clever and a more logical way.

The fact that dos-boxes under Win98 and WinXP behave differently, shows that even Microsoft does not interpret your command in a consistent way.

What else is new about Microsoft?
I am not able to test WinXP so I don't know how different WinXP behaves. What does the line below do in Windows XP?
ren AAAA.AAAA.123456789 B.B.B*

Did you try to get the correct results using TC's Multirename tool, too?
Successfully or without success?

With the rename tool I can get practically every result I want to but that is not the point.

[karlchen]

CMD.EXE-window in WinXP:
ren AAAA.AAAA.123456789 B.B.B* gives B.B.B23456789

Your new examples for TC indicate that I was wrong in assuming that TC acts in a very clever way.

I am still hoping Christian Ghisler might drop in and provide some clarification on how TC interprets such commands and if there is a common specification which all programmes should follow (looks as if there isn't.)

Regards,
Karl

[white]

CMD.EXE-window in WinXP:
ren AAAA.AAAA.123456789 B.B.B* gives B.B.B23456789

I get the same result with COMMAND.COM in Windows 98. So it seems WinXP does not differ too much from Windows 98, but that I had chosen bad examples so it looked like WinXP works completely different.

[ghisler(Author)]

Renaming is indeed a problemantic subject when multiple dots are involved - there just isn't one logical solution, there are always many. I have tried to implement it in a way which seemed the most logical to me, especially because I found no "standard" way to do it...

[karlchen]

@Christian Ghisler

Thanks a lot for settling our futile little argument about how renaming filenames should work when double dots and wildcards are used in the target specification.

Kind regards,
Karl

[white]

Renaming is indeed a problemantic subject when multiple dots are involved - there just isn't one logical solution, there are always many. I have tried to implement it in a way which seemed the most logical to me, especially because I found no "standard" way to do it...

In TC do:
rename AAAA.AAAA.123456789 into B.B.* results in B.B.3456789

I am very interested in knowing how this can seem logical? Maybe someone can explain the logic behind it?
To me it looks like TC sees the first period in the mask of the new file name as separator between file name and extension. Which I think is very wrong because this would suggest there can be periods in the extension, which cannot be.

I have tried to implement it in a way which seemed the most logical to me, especially because I found no "standard" way to do it...

Situation before LFN:
The period in a file name separates name and extension.
When renaming with wildcards the period separates the mask for the file name and the mask for the extension.

Current situation:
The last period in a file name separates name and extension.
When renaming with wildcards the last period separates the mask for the file name and the mask for the extension. There might be a few exceptions here and there, but I think this is how it globally works in all Windows versions(see footnote 1).

This seems like a standard to me. What can be more standard than how it worked since DOS x.x? Ofcourse in the exceptional cases where the different Windows versions behave differently you must deside for yourself what to implement.


(footnote 1) I have not much knowlegde beyond Windows 98, so if anyone can tell me wrong please do so.

[WatchUer]

......
Current situation:
The last period in a file name separates name and extension.
When renaming with wildcards the last period separates the mask for the file name and the mask for the extension. ......

I support your opinion. I had also thought this when I rename a file with the asterisk, and I didn't understand the result until read these posts.

[jb]

The last period in a file name separates name and extension.
When renaming with wildcards the last period separates the mask for the file name and the mask for the extension.

Yes, this interpretation seems very logical and most useful to me.

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.