X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) Message-Id: <10504020442.AA24031@clio.rice.edu> Subject: Re: DJGPP v2.04 Bugs - suggested patch To: djgpp-workers AT delorie DOT com Date: Fri, 1 Apr 2005 22:42:01 -0600 (CST) In-Reply-To: <01c5369e$Blat.v2.4$57206280@zahav.net.il> from "Eli Zaretskii" at Apr 01, 2005 11:35:51 AM X-Mailer: ELM [version 2.5 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavis-20030616-p6 at mail.rice.edu X-DCC--Metrics: handler7.mail.rice.edu 1066; Body=1 Fuz1=1 Fuz2=1 Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > > - r.x.bx = (oflag & 0xff) | 0x1000; /* 0x1000 is FAT32 extended size. */ > > - /* FAT32 extended size flag doesn't help on WINDOZE 4.1 (98). It > > - seems it has a bug which only lets you create these big files > > - if LFN is enabled. */ > > The comment above indicates the FAT32 extended size doesn't work anyway > > without LFN. The code breaks microsoft networking. See test results > > from user below. Comments? Any reason not to commit? > > You mean, you want to remove the extended-size feature entirely? That > sounds somewhat drastic: why punish everybody for the benefit of a > few? I'd rather try with the bit set, and if it fails, try again > without it. Would that work? The patch only removes the extra bit when LFN is not enabled. The comment above indicates the code above doesn't do anything anyway. If LFN is on (and we use the LFN versions of the calls) it should still work. If someone can find a short name only environment that needs files over 2GB, and can show they work, I would suggest they re-write the code to support it, without breaking DOS networking. I still use the DJGPP toolkit on my Ghost Boot disks, which use MS networking to store the images on remote boxes. I hadn't seen this bug since the disks are all still using V2.03 based utilities. Not being able to open any existing file on a network share is a *BAD* bug.