Total Commander

MVV wrote:... but problem would be solved if TC made file copy in temp folder instead (there are full permissions in temporary folder...

Actually, you suggested this in the first place, and I do agree with you, perhaps you misread my previous reply.

mame wrote:in long run the %TEMP% copy method might be better solution

MVV wrote:And, only NTFS volumes allow to set file permissions, so there will be no problems on FAT volumes.

Of course it is. That's why i explicitly gave examples of FAT32 drives as %TEMP% in Question (a).
In case you again misunderstand my points (I hope not ):
- I make assumption that TC copies permission on file copy, so the problem would be triggered during restoration.
- Point (a) is a less preferable method (prone to error), as being illustrated (I did make it clear, I hope). Point (b) is not so safe, in case something goes wrong (TC crashed, accidentally closed etc) coz remembered permission might get lost. Point (c) has advantage, say TC implement a 'recovery' steps after the 'accidental close' so that the work can continue, and permission is *not yet* set, waiting until editing is done and file is being put back. So a<b<c

Regards, Matt.

Balderstrom wrote:...as a .bak file that had nothing to do with TC already existed...

.tcbak=Funny suggestion

How can a .bak has nothing to do with the parent file. Is it like this?
1. file1.txt file1.ini file1.nfo file1.diz
2. edited file1.diz with some editor which saved the backup as file1.bak
3. come tc, compare and edit file1.txt.
4. finished edit, tc overwrites file1.bak

If that's the scenario, I can only blame myself, not TC

Regards, Matt.