Sharing-violation when accessing a file opened for delete access - for SOME operations

[gigaman]

I noticed a strange behavior (inconsistency) when accessing a file currently open for Read+Write+Delete access. While such a file can be e.g. opened in Lster or copied in standard mode, it cannot be copied when "Use standard copy method" is unchecked, the file content isn't searched with Alt+F7, cannot be compared using "Compare by content". (There are probably other operations.)
I can't rule out the possibility that the behavior is intentional - but since F3/Lister works, it looks like a weird inconsistency.

Technically:
Let's suppose an application created/opened a file and included a DELETE access, e.g. via

Code: Select all

CreateFile(..., GENERIC_READ | GENERIC_WRITE | DELETE, FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, ...)

has written some content there and is still running and has the file still open. When I navigate to that file in Total Commander and press F3, it attempts to open the file with FILE_SHARE_READ | FILE_SHARE_WRITE. That attempt fails with ERROR_SHARING VIOLATION, and TC retries with FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE - which succeeds.
However, when I try to copy the file using F5 (with "Use standard copy method" disabled), an open with FILE_SHARE_READ is attempted (which fails), and there's a retry with FILE_SHARE_READ | FILE_SHARE_WRITE (which also fails because FILE_SHARE_DELETE is missing). When TC tries to open the file during a content search via Alt+F7 or Compare by content, there's only one attempt with FILE_SHARE_READ | FILE_SHARE_WRITE (which, again, fails because of the missing FILE_SHARE_DELETE).

So, my question is - would be possible to add FILE_SHARE_DELETE to those file open calls?

(I reproduced this with TC 11.5 b5 but I believe it's been a long time like this.)

[ghisler(Author)]

Only lister tries with FILE_SHARE_DELETE if initial opening fails.
Have you tried with "Use standard copy method" enabled? This uses CopyFileEx - I wonder what it uses...

[gigaman]

Yes, "Standard copy method" works, "non standard" doesn't, and searching/comparing content also doesn't (there's no retry for search/compare).
I'm not sure there are any disadvantages to using FILE_SHARE_DELETE (at least for a retry)... maybe it would always be beneficial?

[ghisler(Author)]

OK, I will add it to copy, compare by content, and synchronize dirs.

[ghisler(Author)]

This should work now in beta 6, please test it!

11.11.24 Added: Try to open file with FILE_SHARE_DELETE flag if it failed without it in copy function, synchronize dirs (by content), and compare by content (32/64)

[gigaman]

Yes, it works now - thanks a lot!

There's a few more operations I found where it doesn't work and the open fails with sharing violation:
1. When I use Synchronize directories, select an unequal file (one of them being the one where Delete sharing is required) and then use Ctrl+F3 (Compare left & right)
2. Pack file (e.g. to ZIP)
3. Encode File
4. Create Checksum File

[ghisler(Author)]

Thanks for confirming the fix!

There's a few more operations I found where it doesn't work and the open fails with sharing violation

There are 100s of locations where I would have to add this manually, but this would never end. Therefore I will not add it to other locations for now.

Moderator message from: ghisler(Author) » 2024-11-18, 09:28 UTC

Moved to will not be changed