-[8.52 x64 RC1] Copy w Overwrite: filename not preserved

The behaviour described in the bug report is either by design, or would be far too complex/time-consuming to be changed

Moderators: Hacker, petermad, Stefan2, white

Post Reply
MarcelS
Junior Member
Junior Member
Posts: 4
Joined: 2015-08-20, 12:25 UTC

-[8.52 x64 RC1] Copy w Overwrite: filename not preserved

Post by *MarcelS »

ISSUE: Filename capitalization is not preserved when overwriting files

How to reproduce:
1) Create a text file titled: "a.txt" (all lowercase). Write the small "a" inside the file.
2) In different directory, create a text file titled: "A.txt" (note capital "A"). Write capital "A" inside the file.
3) Copy the file "A.txt" to directory where the file "a.txt" is located.
4) You will be asked to Overwrite: "a.txt" with file: "A.txt". Click the "Overwrite" button.

Now, you can see that the filename of the overwritten file is still "a.txt", but the content of the file has been changed to "A".

I think the proper behavior would be to replace the content of the file and also to change the filename so that the capital letters of the new file are preserved. The reason for that is that if I click the overwrite button I very likely do not care about the old file but want to keep the new file. Moreover, before overwrite operation the Total Commander asked me if I let him to: "Overwrite a.txt with file: A.txt". But he just copied the content of the file.

Unfortunately the same behavior can be found in Windows, which I still believe is incorrect. By the way, in the same situation the Win 10 will notify you that 'The destination already has a file named "A.txt"', which is not correct since the name of the old file is "a.txt" :wink:
User avatar
Horst.Epp
Power Member
Power Member
Posts: 6976
Joined: 2003-02-06, 17:36 UTC
Location: Germany

Post by *Horst.Epp »

The file to be overriden is still the old name, so for me its ok to stay with it.
As TC follows the Windows logic all is fine :D

The Windows file system is not case sensitive
so its just a cosmetic or personal preference issue.
MarcelS
Junior Member
Junior Member
Posts: 4
Joined: 2015-08-20, 12:25 UTC

Post by *MarcelS »

Horst.Epp wrote:The Windows file system is not case sensitive
so its just a cosmetic or personal preference issue.
Especially due to the fact that Windows files system is not case sensitive there must be some logic introduced into copy operations.

Imagine this common situation: you have your own web site running on a Linux server. On the server you have an html file which links to an image titled "A.jpg". But on your personal computer running on Windows you have the latest version of your web site which you develop. In your latest version you change the filename of the image to "a.jpg" and the link inside the html file. Now you want to upload your latest version of the web site to the server. During copy operation you will be asked to overwrite the file. Unfortunately the filename capitalization will not be changed. So your html file will link to "a.jpg" which does not exist. But did I make a mistake somewhere? No, I did not. The error happened during copy operation which is hard to predict.

The problem can also happen when you backup some directories by simply copying them to different hdd and overwriting the current copy. When you will recover from this backup the filename capitalization might be different as in the original location.
User avatar
milo1012
Power Member
Power Member
Posts: 1158
Joined: 2012-02-02, 19:23 UTC

Post by *milo1012 »

MarcelS wrote:Image this common situation: you have your own web site running on a Linux server...
Since basically all decent Linux-based FTP systems are case sensitive, the server would take the new file correctly.
Please don't mix Win API operations with remote FS operations.
MarcelS wrote:Especially due to the fact that Windows files system is not case sensitive there must be some logic introduced into copy operations.
Yes, and with a simple logic you can think of it by yourself: both files are seen as identical names, so the existing name will stay that way. That's the whole point of case-insensitive systems!
RL comparison: you are colorblind and replace the content of a (physical) folder with a different batch of papers from another folder. Would you now paint that folder in the same color as the folder where the new content comes from?

In other words: there will be no additional rename operation by default, which is one of the reasons why case-insensitive systems were developed, because file system operations are (were) time intense.
And so the original name will stay, unless you manually force it to change.
TC plugins: PCREsearch and RegXtract
User avatar
MVV
Power Member
Power Member
Posts: 8711
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV »

I'm quite often use current TC logic, it is very useful. E.g. I have Readme.txt in a dir and I overwrite it with ugly named README.TXT file, it is a nice feature that TC keeps original name.
User avatar
petermad
Power Member
Power Member
Posts: 16032
Joined: 2003-02-05, 20:24 UTC
Location: Denmark
Contact:

Post by *petermad »

2MVV

I too find TC's way (hence Windows' way) useful - but I can also think of situations where the opposite behaviour could be useful. An internal command for toggeling betwen the to ways could be nice, or at least an ini-option.
License #524 (1994)
Danish Total Commander Translator
TC 11.51 32+64bit on Win XP 32bit & Win 7, 8.1 & 10 (22H2) 64bit, 'Everything' 1.5.0.1391a
TC 3.60b4 on Android 6, 13, 14
TC Extended Menus | TC Languagebar | TC Dark Help | PHSM-Calendar
User avatar
Hacker
Moderator
Moderator
Posts: 13142
Joined: 2003-02-06, 14:56 UTC
Location: Bratislava, Slovakia

Post by *Hacker »

Just my two cents, I would expect the filename to be overwritten, too. I understand it's not standard behavior but I'd find it more logical. In my eyes, I am replacing the whole file, not just the contents of the existing one.

Roman
Mal angenommen, du drückst Strg+F, wählst die FTP-Verbindung (mit gespeichertem Passwort), klickst aber nicht auf Verbinden, sondern fällst tot um.
MarcelS
Junior Member
Junior Member
Posts: 4
Joined: 2015-08-20, 12:25 UTC

Post by *MarcelS »

milo1012 wrote:In other words: there will be no additional rename operation by default, which is one of the reasons why case-insensitive systems were developed, because file system operations are (were) time intense.
I understand what you are saying but I think the current behavior could be improved a bit.
The TC could use case sensitive comparison to compare filenames and only rewrite those names which have different capitalization. That would not hurt the copy operations much I guess. It is just my opinion.
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 50550
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) »

The current behaviour is what other file managers including the Explorer do, so I don't think that it would be a good idea to change it.
Author of Total Commander
https://www.ghisler.com
MarcelS
Junior Member
Junior Member
Posts: 4
Joined: 2015-08-20, 12:25 UTC

Post by *MarcelS »

ghisler(Author) wrote:The current behaviour is what other file managers including the Explorer do, so I don't think that it would be a good idea to change it.
Total Commander is a file manager. A little experimentation with new ideas in file management should not matter in this case. Quite on the contrary, this should be expected from such software, I think. But of course, it is up to you.
User avatar
MVV
Power Member
Power Member
Posts: 8711
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV »

I think that INI option won't hurt, if it will allow switching between two behaviours (overwrite on copy/move/unpack with preserving source or target filename).
User avatar
Valentino
Power Member
Power Member
Posts: 709
Joined: 2003-02-07, 00:21 UTC
Location: Ukraine

Post by *Valentino »

I also like current behavior but I understand MarcelS and he is probably not alone, so INI option would help.
Post Reply