Edit mode, backup file.

[mame]

In Synchronize -> Compare -> Edit mode. Files edited, then saved, will always have a *.bak backup.
Can that be turned off (with option to turn on again)? Or did I miss something...?

Some people may not need backups for some TXT files. Say, an intermediate/advanced TC user comparing and editing revisions of wincmd.ini (I do).
Moreover, one can't edit binary files using the built-in editor, so nothing serious can go wrong, I think...

[petermad]

Right now we have two options for use in wincmd.ini:

CompareSaveOriginal=1
1: When saving, the file is copied to filename.bak, then the data is written to filename. Advantage: additional streams, special attributes etc. are preserved.
0: When saving, the data is written to filename.tmp, then the file is renamed to filename.bak, and finally filename.tmp is renamed to filename. Advantage: The file has to be written only once, and remains intact in case of a write error.

Support for a third option:
2: Don't save any backup file.

[mame]

umm.. I suppose option (2) doesn't yet exist does it? not in helpfile, tried tho.
then i re-read your post. duh.

looks like i have to write a batch file for that:

@echo off
:loop
del /f/s/q/a C:\*.bak
:goto loop

put to Startup folder

I hate *.bak the most...

[petermad]

umm.. I suppose option (2) doesn't yet exist does it?

Right - thats why I support it as a new feature, according to your original request.

[MVV]

I've suggested to create backup copies in separate temp folder, it would allow to remove them quickly, but...

[ghisler(Author)]

Because of the file mapping, TC needs to access the old and new file at the same time, there is no way to get rid of the .bak file completely. But what I could do is delete the .bak file once the new file has been written.

[petermad]

But what I could do is delete the .bak file once the new file has been written.

That's good enough for me

[mame]

But what I could do is delete the .bak file once the new file has been written.

That's good enough for me

Yes, me too. (That's what I'm talking about)

[MVV]

I think more than one last backup files in temp folder would be useful for some users, especially in case of editing multiple files at the same time. Also some INI that keep their original paths and names.

[petermad]

backup files in temp folder

That's also a good solution.

[MVV]

Sometimes it is a best solution:) e.g. I have write-protected folder where only some files have full permissions (cfg files) - it is a normal situation for years (at least since UAC has been introduced). Currently it is impossible to compare-and-edit such file because TC fails to save changes at bak creation stage. It just suggests to save changed file into another place (and it is completely unuseful because I need to spend some time for choosing where to save it and move it back manually after comparing).

[ghisler(Author)]

But what I could do is delete the .bak file once the new file has been written.

This has been added to beta 12 now. It's deleted only when you close the compare tool. Also only one .bak per side can be deleted, e.g. not all .bak files will be deleted if you compare, edit+save, then load 2 different files and again compare, edit+save.

[mame]

This has been added to beta 12 now.

Thanks! Works flawlessly, 32/64 bit. And file permission was intact.
(CompareDeleteBak=1)

Tested: compare/edit *.bak files also works (file.bak -> file.bak.bak)
Note: *.bak file is treated as a new, different file which inherited parent folder permission.
If original file has a different permission, only original (edited) file gets back the original permisson. Clever.
Is it done automatically or TC has to do some workaround?
(CompareDeleteBak=0)

On second thought I guess this is what MVV talked about:

...one last backup files in temp folder...
...TC fails to save changes at bak creation stage...
...e.g. I have write-protected folder where only some files have full permissions...

I'm not sure if what MVV was suggesting is what I think it is, but I'll try to elaborate some... Good suggestion nevertheless, but I think real-world implementation would involve some more work to be done during the process.

Example:
1. C:\Share\ (admins, operators, local users: rw. guest, everyone: ro)
2. C:\Share\example.txt (everyone: rw)
3. Say I'm guest. Now if I put the temporary example.txt in my own %TEMP% it would be "owner:guest" Now after editing, put back into C:\Share. Guess what would happen?

Question: When should TC read the file permission?
a) When initially copying C:\Share\example.txt, read its permission and copy it to my %TEMP% (I'm no admin, so NTFS permissions as permitted to me only). Can be bad actually, say my %TEMP% is a FAT32 drive... (ramdrive, pendrive etc)
b) Same as above, but instead of copying, save the permission in program memory until the file is written back. (Could work, I think)
c) When copying from %TEMP% to C:\Share, read the (original, C:\Share\example.txt) permission and set the (newly copied file) permission accordingly. I think this method might also work.

Come to think of it, in long run the %TEMP% copy method might be better solution VS current *.bak method. But that's my opinion. YMMV.

[MVV]

mame, TC doesn't read/write permissions at all, it just opens file for writing and writes data, and permissions are kept. But if there is no write permission, OS doesn't open file for writing and reports error.

Currently TC always creates backup file in same folder with file to be modified (it just makes a copy of original file), but problem would be solved if TC made file copy in temp folder instead (there are full permissions in temporary folder, also there is a write permission for edited file).

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

[Balderstrom]

Couldn't we get an option to choose the extension name? (eg .tcbak)I know it's been requested before. I also know I've lose data on multiple occassions as a .bak file that had nothing to do with TC already existed prior to the compare tool overwriting it.