lenst

On 32bit linux fopen can't open large files (>2Gb i think). System.cpp uses fopen to test if a file exists. The code that reads the files uses open (not fopen) with flag O_LARGEFILE. Before the map patch these files where just read, not tested for existens. One solution could be to change the exitens test to use open. The following patch works for me:

--- a/contrib/extractor/System.cpp
+++ b/contrib/extractor/System.cpp
@@ -1,6 +1,9 @@
#define _CRT_SECURE_NO_DEPRECATE

#include <stdio.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
#include <deque>
#include <set>
#include <cstdlib>
@@ -81,9 +84,10 @@ void CreateDir( const std::string& Path )

bool FileExists( const char* FileName )
{
-    if(FILE* fp = fopen( FileName, "rb" ))
+    int fd = open( FileName, O_RDONLY | O_LARGEFILE );
+    if(fd >= 0)
    {
-        fclose(fp);
+        close(fd);
        return true;
    }

I ran small tests and did come to result that linux refuses to read 3 .MPQ files...

These files are common, common-2 and new lichking one.

In other way I tried to open them in text editor and text editor fails to open them as well where as it can open others... So I have no idea what causes the real problem...

These are large files. That might explain why the text editor can't open them. They are all larger than 2Gb. I think they are the only files that large.

I put in some printfs and found that fopen fails with "Value too large for defined data type". But why now? What changed in the patch that could have an effect on this? Any change in libraries or compiler settings?

I'm running mangos on Linux and I still have problem extracting the new map files. I have recompiled ad according to instructions. Running it generates 1206 maps files, but the lowest numbered file is 2692527.map. No 0004331.map gets generated.

Perhaps the difference is in whitespace. Have you tried a diff with -b or -w ?

Whitespace could also be LF vs. CRLF.