+[TC8.50b9] 'Not enough memory' causes wrong compare result

[MarcinW]

I've made some additional research and it seems that side effects of using file mappings cannot be avoided:
- when using a file handle with share mode FILE_SHARE_READ to create a mapping, applications like Notepad can't write to the file,
- when using a file handle with share mode (FILE_SHARE_READ or FILE_SHARE_WRITE), applications like Notepad can't make the file shorter - when user deletes some lines of text, there will be garbage eat the end of file.

I don't know if there is any particular reason for using file mappings when comparing files. Using file mappings doesn't seem to improve performance - in both cases whole file must be read: when reading the file directly with ReadFile or when using a file mapping (so operating system reads the file). I can see only side effects: there are problems with file sharing and it's impossible to compare files that are larger than available address space.

So, in my opinion, file mappings should be avoided both in the initial compare phase and also inside compare window. They should be replaced with ReadFile + additional support for ERROR_LOCK_VIOLATION error - see the algorithm in my previous post. Only in case of ERROR_LOCK_VIOLATION error, file mappings should be used to overcome the file locking. In this specific situation, using a file mapping is better than not using it - because user gets what he surely wants (can compare the file, even when it is locked), and the possibility of side effects is very small: if some application keeps a region of file locked, it can still write to the file, and also file mapping will be created for a very short amount of time.

So, as a summary: changing file mappings to ReadFile calls would be better for the user, because:
- he will be able to edit files that are being compared, even if files are > 1MB,
- he will be able to compare files even when locked,
- he will be able to compare files larger than the available address space.

Regards

[ghisler(Author)]

I will consider it for a later version. For now I prefer not to change it, the risk is too high to break a lot of things.

[MarcinW]

Sure.

[joker]

I think TC should map not whole files but parts of them (e.g. 64MB blocks) and then move window so it wouldn't require such ammount of memory. When difference is found, TC may load entire files for compare tool in order to show differences (if it is too hard to use window with limited size).

I second that.
Take for example the very fine software WinHex.
WinHex has no problems at all to compare files of any size because it does so block wise - and there even isn't a 64-bit executable of WinHex!
So why is TC *still* - I mean after so many years of existence - not able to do that?

[ghisler(Author)]

Sorry, it is too complex and causes too much slowdown. If you really need this, use the 64-bit version.