Date:	Sat, 02 Dec 2000 10:49:26 +0200
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	pjfarley AT banet DOT net
Message-Id:	<1438-Sat02Dec2000104925+0200-eliz@is.elta.co.il>
X-Mailer:	Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6
CC:	eplmst AT lu DOT erisoft DOT se, djgpp-workers AT delorie DOT com
In-reply-to:	<5.0.1.4.0.20001201234954.0347fec0@pop5.banet.net>
	(pjfarley AT banet DOT net)
Subject:	Re: Locking fcntl() and flock() patches
References:	<200012011435 DOT PAA09759 AT lws256 DOT lu DOT erisoft DOT se>
	<200012011435 DOT PAA09759 AT lws256 DOT lu DOT erisoft DOT se> <5 DOT 0 DOT 1 DOT 4 DOT 0 DOT 20001201234954 DOT 0347fec0 AT pop5 DOT banet DOT net>
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

> Date: Sat, 02 Dec 2000 00:30:41 -0500
> From: "Peter J. Farley III" <pjfarley AT banet DOT net>
> 
> I went to the url that Mark pointed to, and I see the "transitional" 
> rules that allow this type of enhancement.  It seems easy enough to add 
> the #define that says we handle 64-bit file offsets, and the bits that 
> apply to fcntl() 64-bit functionality depending on that #define, but 
> there are a *whole* lot of *other* 64-bit I/O functions involved in 
> setting up a complete 64-bit file environment.  I'm *not* sanguine 
> about being able to get all of those written and installed correctly, 
> and I'm of the opinion that 64-bit file locking is really useless 
> without 64-bit file *access*.  I would submit that 64-bitness for DJGPP 
> is an entirely new project, separate from enabling locking in fcntl(), 
> and quite frankly better handled by someone with more intimate (and to 
> the point, more practical) internals knowledge than I possess at this 
> time.

Sorry, this is a misunderstanding.  I didn't mean to imply that you
should write 64-bit file support for DJGPP as part of improving fcntl.
What I meant is that it would be nice to include FAT32 support that is
_already_ part of the CVS sources for `_open', `_read', and `llseek'
(added by Martin).  FAT32 allows support of up to 4GB file-size.  This
is stil 32-bit, but it uses the entire 32-bit width of the registers.

The issue of supporting FAT32 in fcntl boils down to adding a few more
case blocks which accept F_RDLCK64 etc. commands and manipulate the
64-bit equivalent of struct flock, but otherwise do the same.

> AH = 5Ch
> AL = subfunction
>      00h lock region of file
>      01h unlock region of file
> BX = file handle
> CX:DX = start offset of region within file
> SI:DI = length of region in bytes
> 
> Now, unless all of CX, DX, SI, and DI are DWORD's, that's only 32 bits 
> each for the offset and the length.

FAT32 still uses 32-bit values, but they are unsigned.

The question whether 215C supports FAT32 is an open one: I asked that
here as part of this discussion; hopefully, someone could try that and
provide an answer.

I agree that if 215C doesn't support FAT32, this is a moot point, and
we should simply document that fact and continue.

- Raw text -