bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Roland Schwingel
Subject: NSData: Bug in windows code for reading/writing a file
Date: Mon, 14 Apr 2003 11:03:20 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]