TC Compare doesn't set FILE_SHARE_WRITE when open Files

[HAL 9000]

... the effect of this is that no other program can alter the file as long it is opened in TC-Compare like this.

Background: FILE_SHARE_WRITE is a flag you set in ShareMode that is pass to API CreateFile (together with of course the FileName the desired Access and the open Mode)

Details:
Debugging Totalcmd.exe I found out that ...
[to be continued I got vistor (I'll edit this)]
Continue
... TC opens each file twice on compare.
The first time it's opened with FILE_SHARE_WRITE (making this fail gives Error: Left File not found)
The second time it's opened only with FILE_SHARE_READ (making this fail gives Error: Left File Read Error)
I patch this one change some flag value from 0x20 to 0x0 that makes CreateFile to be called with FILE_SHARE_WRITE just as the first one.

However a bigger undertake might be to disable the TC selfcheck thread to 'manifest' that change to the exe however I just did it for fun since:
Image: http://secretgeek.net/image/real-programmers-code-in-binary.jpg

The problem:
Now is that open the file with only FILE_SHARE_READ locks it so no other app like for ex. an editor can save it.

TC compare notifies if the files current opened were changed but if you can't write the file this functionality get's block.


And when being on fixing this maybe take time to think about adding FILE_SHARE_DELETE as well. Background for this is that now you will also able to open files that were created with FILE_FLAG_DELETE_ON_CLOSE.
Well having it opened like this in TC compare will preserve it from being deleted, until you close it in the TC compare - since the OS deletes the file after all handles are close.

My TC Version is 8.51a.

[milo1012]

So what exactly is your topic now?
The sharing mode for TC Compare, or for TC-Lister, or both ?

Background: FILE_SHARE_WRITE
Only since the recent years, many common programs tend to open files with it.
But you really need to know what you're doing, as it may result in a lot of trouble.
Many tasks can live with the fact that a file is altered while being read (like media files),
but definitely not all!

I won't use FILE_SHARE_WRITE for my plug-ins too, for the simple reason that the
file needs to be consistent for the entire read operation, because I do an initial analysis of it.
If the file is now being altered (due to that flag) while I read it progressively,
I can't guarantee accurate results, and display wrong things about such file.
The same applies for TC's CBC: if you allow programs to write while you read it in portions until the end,
you may get wrong results.
That's the whole point of the CBC tool: to do an accurate compare, isn't it?

You might want to take a look at
http://www.ghisler.ch/board/viewtopic.php?t=39642
if you're really talking about CBC and files > 1 MB.

Debugging Totalcmd.exe I found out that...

No need to debug. Using things like ProcessMonitor will show you the sharing mode also.

[HAL 9000]

So finished please read again my initial post.

So what exactly is your topic now?
The sharing mode for TC Compare, or for TC-Lister, or both ?

Sorry for confusion - this was just a not-integrated-copy&paste-fragment at the end of my posting text.
Subject is about TC Compare.

Debugging Totalcmd.exe I found out that...

No need to debug. Using things like ProcessMonitor will show you the sharing mode also.

I know and sometimes use it. Btw if you don't now try this API Monitor .
However in situations like this I like to use Ollydbg or X64Dbg that give more possibilities to investigate whats around some API-call I focused on and to abilities to alter/fix things.

Background: FILE_SHARE_WRITE
I won't use FILE_SHARE_WRITE[...]
If the file is now being altered (due to that flag) while I read it progressively,
I can't guarantee accurate results, and display wrong things about such file.
The same applies for TC's CBC: if you allow programs to write while you read it in portions until the end,
you may get wrong results.
That's the whole point of the CBC tool: to do an accurate compare, isn't it?

Okay i see the point. And I agree that the file should be lock for writing when the file is read for comparing. However when after that as long as the compare results are shown the file should be held open to get notification about possible changes - but in this stage it should be opened with FILE_SHARE_WRITE.

However once created you can't change a filemapping that was 'read' to 'readwrite'. So just open it as 'readwrite'. That might clash with the concept of reading stage during compare only with FILE_SHARE_READ. However as long there is set a 'notification handler' that informs you about if the file was altered everything will be fine.
Results will be accurate. If there was are write during the readin&compare stage you get a notification that informs you that compare results are outdated and needs a recompare to be accurate again.
Of course knowing that changes might occur during read, you should take care in you're implementation to query always the file size from the system since it can change.

Well at the moment I've no experience yet about how the 'file notification handler' is done and what constrains/limitations it might oppose to the implemention.