Compare by Content -> Edit mode vs Read Only files

[pjotrb]

Hi,

In Compare by Content I clicked Edit on a pair of Read Only files.
I made some changes to the file on the right, saved it by clicking [Compare] and choosing Save Right.
The original file xyz.txt was renamed to xyz.txt.bak, and a new file xyz.txt was created.
The result:
- xyz.txt.bak (Read Only).
- xyz.txt (Writable).

issue 1: There were no warnings for the Read Only file, which I think is a shortcoming.

Then I made some more changes to the file on the right, and I tried to save it again by clicking [Compare] and choosing Save Right.
issue 2: I got a "File Write error !", because now xyz.txt.bak exists and is Read Only. There is no Overwrite option.

After this I tried to exit Compare by Content by choosing any of the first 3 options that follow the Esc-key: Save Right, Save Right As, Don't Save.
issue 3: All 3 options produce the same "File Write error !". Yes, even Don't Save does this.

The only way to get out of this is (a) kill TotalCmd 7.0 beta, or (b) remove the Read Only-bit behind its back, and then try Save or Esc again.

Bye,
Peter

[ghisler(Author)]

Hmm, so what would you suggest? It seems that the read only attribute didn't prevent the rename function from working. Should TC refuse to save to a read only file by checking its attribute manually?

[pjotrb]

Maybe like this:

As soon as I start to modify a file in the editor, and the file is read only, show a "File x:\path\xyz.txt is read only, are you sure you want to edit?" dialog.
Pressing No -> changes not allowed (unless I do it again and press Yes).
Pressing Yes -> editor allows edits, and Save removes the read only flag (not sooner, because I could still choose Cancel).
The dialog might be shown as soon as I press [Edit], or it could be delayed until I actually do something on a file which is read only.
This should work for both files separately of course, because I may edit one or both, and one or both may be read only.

Also please make it robust for unwritable directories/partitions/network shares (as a result of insufficient user rights). And for CD-Roms, etc. And for hackers like me who would set or restore the read only flag behind its back, just for fun

Peter

[pjotrb]

One more thing:

In my case the Read Only flag is usually controlled by Visual Source Safe (stupid me forgot to check it out).

Therefore I'd like to be able to press No; check out the file using VSS; and then the Compare by Content tool should notice by itself that the Read Only flag has gone and allow my edits from then on.
(It would also notice if the file has changed due to the checkout, and offer to reload - which it does already!)

Peter

[sqa_wizard]

Caution: This *.BAK feature is dangerous.
It works like almost every tool does it:
1. Rename original to *.BAK
2. Work on the copy

In case of Source Control as well as on NTFS-Hardlinks this means: The *.BAK file is still under Source Control / destination of the NTFS-Hardlink.

The new file is just out of scope now.

The more save behaviour is:

1. Save a copy as *.BAK
2. Work on the original file

This way you keep all file relations.

[ghisler(Author)]

Hmm, this would mean that the file would have to be written twice on each save operation?

[pjotrb]

Hmm, this would mean that the file would have to be written twice on each save operation?

In that scenario, yes.

However I think that this would not be necessary, because I believe that the scenario that sqa_wizard gives is not realistic: as far as I know, VSS (or Team Foundation Server using the VSS-provider) does not use file locks or low-level file ids, or anything like that. It simply checks in whatever file exists with the path+name that it is looking for. Correct me if I'm wrong; with a link to MSDN please

Peter

[sqa_wizard]

I believe that the scenario that sqa_wizard gives is not realistic

I had it once using ClearCase (resulting in a View Private file) and whenever I edit NTFS-hardlinks.
VSS is even simple, so may it looks for the name only.

I configured my editor to not creating BAK files. This is not very save, but the only way to stick on the original file.

In case of TC, there is no such option (yet) ...

[Flint]

BTW, there is one more problem with creating BAK files by means of renaming: all additional NTFS streams remain in BAK file only! So, after you remove the BAK file, all its streams are gone which is quite unexpected for the user (suppose it was a downloaded and potentially dangerous HTML file. The system adds an additional stream and on every start warns the user. After editing with BAK-renaming the saved HTML file will not be marked as dangerous anymore.)

[ghisler(Author)]

Is it better now? I haven't implemented the double saving yet, but you should get a warning now with read only files.

[Flint]

Yes, the warning is shown now.
But it is still the BAK that becomes read-only after saving, not the original file! This may be confusing...