Thanks for looking into this and giving such detailed info!!

I'm not sure it works on every platform, maybe @Itms would know.

It won't since clip.exe is a windows tool...
But on the other hand the current solution in the wiki isn't working at all on windows with TortoiseSVN installed. So just adding this shouldn't be that bad :)

Upload patch again with new master revision and full file context.

Ahh! Thanks a lot. This did the trick - here is the full patch with context.
Maybe your cmd command could be added to the wiki page so others don't run in this trouble too?

In D2088#89115, @vladislavbelov wrote:

Could you add a context to the patch?

Regarding the use of GetLastError() for a more detailed error info there are several issues that should be considered first:

Moved the include statement. Using the win fuction GetLastError() isn't that easy in this context, see code comment

Fixed typo

Changed comments and macro name. Works on Windows, logs error correctly.
In many cases pyrogenesis is still crashing afterwards because other components try to read non-existent files. Therefore passing the error to the caller isn't enough and we should keep the LOGERROR line there to preserve the crash information.

In D1274#52775, @elexis wrote:

Sure about this? We have these things that allow multiple inclusions of header files

...
#ifndef INCLUDED_XEROMYCES
#define INCLUDED_XEROMYCES

Yes, I know about these preprocessor constructs. But I think this will not work because ifndef can't be used for macros (since they contain a #define statement). I did some basic test but couldn't get it working.

Unfortunately I couldn't fully test this revision since I stumbled across a quite strange problem:
(it stopped at the breakpoint and I klicked on "step into" once)

Changed the error return value.
Unfortunately I had to include FileIo.h to be able to use PSRETURN_File_WriteFailed. Couldn't define it in Xeromyces.h since FileIo.h and Xeromyces.h are included simultaneously in some other files which would then lead to a redefinition of ERROR_GROUP(File);.

Complete rework. Had to introduce a new macro to convert the "+1" error to a "-1" error.

Ok, now this makes sense, thanks for the links. And yes, my diff is absolutely useless because I just ignore the error now...

Thanks for pointing me to status.cpp - now i've realized the status is just a 64 bit signed int. Interestingly enough the status isn't negative but plus 1 most of the time (and sometimes - quite rarely - it is actually zero). I've used debug_prtinf with %I64d for output what should be working?!
To be more specific: The status of SetFilePointerEx and SetEndOfFile are 1 most of the times, but while WARN_IF_FALSE(SetFilePointerEx( don't cause a crash WARN_IF_FALSE(SetEndOfFile( does. Replacing this line with the diff or just entirely removing the Macro (which doesn't sound that good) avoids crashing and the game is working then.

Diff update: Using WARN_IF_ERR instead of RETURN_STATUS_IF_ERR as suggested by elexis

In D1274#51517, @elexis wrote:

To clarify, you're saying it loads all files successfully despite the anti-virus scanner?

Yes, it seems so. But something is going wrong with the the "old" error handling for the handle, because the process dies spontaneously somewhere in the WARN_IF_FALSE-makro - when the anti-virus scanner is active.
With the macro RETURN_STATUS_IF_ERR however it is fully working...