NSData: Bug in windows code for reading/writing a file

[Roland Schwingel]

Hi...

A fews days ago a strange bug appeared when wanting to read a file with 
-[NSData initWithContentsOfFile:] on windows systems. It appears that 
NSData is not able to read files of a certain size (in my case 98383908 
Bytes). But only when loading this file on a windows 2000 or XP system 
using a samba (or PCMacLan) share. On NT everything is fine. When 
accessing a share on windows server or loading the file locally it works 
also on 2000 or XP.

When studying the code you see it uses the win32 call ReadFile(). It 
appears that this call here breaks. (GetLastError() reports that there 
are not enough system resources). So it is a problem of that windows 
call reading bigger files. When reading the file in smaller portions 
using ReadFile() this file (and files in similar size) are
working as well. When trying to write a file of that size (using 
-[NSData writeToFile:atomically:]) I get similar problems. Here 
WriteFile() is used. It obviously suffers the same problem. As thinking 
of a fix I studied the Unix part of readContentsOfFile() and -[NSData 
writeToFile:atomically:] (where the io operation takes place) I see 
there fopen()/fread()/fwrite()/fclose() is used (which are also present 
on windows). In a quick hack I removed all windows specific stuff in 
these 2 functions and it works very well on NT/2000/XP using all types 
of shares using the f...() calls. So it might be a good idea to remove 
all that windows specific stuff to fix this bug (from my POV).

I studied the gnustep CVS and found that in Revision 1.83 (on 
2002/06/30) these calls where added (before the Unix part was used). Has 
there been a reason for doing that?

Changelog just notes:
* Source/NSData.m: MINGW file read and write operations added (untested)

I couldn't yet find any reason to keep the win32 specific stuff here. 
Removing it will fix this bug and simplify NSData a bit, so I suggest to 
remove the win32 calls.
(if you like I can supply the patch)

What do you think?

Roland