[TC 11.03] Compare By Content silently fails if the temporary extraction path is already locked

[tempdrive]

Generally speaking I understand that when a file is opened by Compare By Content, it cannot be modified, though I am unsure if this is the intended design.
Given how it works currently, I have encountered the following error.
If a file needs to be extracted (e.g. from .zip) to %Temp% folder of the user, when trying to do another Compare By Content where the same file name needs to be extracted, the operation will be "silently" blocked.
Technically speaking a Windows notification sound is still being played, but no visual representation of the failed operation occurs.
The origin of the issue seems to be that the same file names are extracted to the same fixed path, which can have a lock on it at the time when the extraction happens.

This is just one of the many ways to simply reproduce the error:
1. Create a file called test.txt and store it 1.zip and 2.zip.
2. This approach will require you to modify the content of the uncompressed test.txt file to ensure you will have different data to compare as the Compare By Content window must be opened.
3. Get inside 1.zip and compare the test.txt file from it with the non-compressed test.txt file and keep the Compare By Content window open.
4. Do the same for 2.zip: Compare test.txt from it with the uncompressed file.
RESULT: Windows error notification sound is played, but no visual representation of the error will happen.

Normally, when you have the file locked in such a way and you try to save over it, you will get the following error pop-up on OS level: "This proccess cannot access the file because it is being used by another process."
The error you are receiving varies given on what program you are using.
Something like this would be nice to have instead of the "silent" failure.

[ghisler(Author)]

There is indeed no error when the file is mapped into memory, so overwriting isn't possible.
You could set a larger value via wincmd.ini option MaxCompareSizeInMem, then TC will overwrite the file and compare it. But this will cause problems editing the first file.

[tempdrive]

Thank you for the response.

I am not sure how to use this parameter exactly, I tried giving it a random integer value (larger than the file size) but nothing seems to have changed in behavior.

Basically how it currently works is fine from my point of view, it was more about receiving some sort of (a telling) display message when the user selects "yes" after being prompted for overwriting the already existing path in the TEMP folder, instead of a silent error.
If sound is disabled/muted or set to nothing for that particular audio notification, there no indication whatsoever why nothing has happened despite the user selected to proceed by clicking on "yes" in the confirmation dialog.