Date: Sat, 02 Dec 2000 18:54:21 +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: <4331-Sat02Dec2000185420+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.20001202095034.0259fd60@pop5.banet.net>
	(pjfarley AT banet DOT net)
Subject: Re: Locking fcntl() and flock() patches
References: <5 DOT 0 DOT 1 DOT 4 DOT 0 DOT 20001201234954 DOT 0347fec0 AT pop5 DOT banet DOT net>
 <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> <5 DOT 0 DOT 1 DOT 4 DOT 0 DOT 20001202095034 DOT 0259fd60 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
Precedence: bulk

> Date: Sat, 02 Dec 2000 10:00:44 -0500
> From: "Peter J. Farley III" <pjfarley AT banet DOT net>
> 
> 1.	How do I get copies of this FAT32 support code, since the copy of 
> djlsr203.zip that I have does not contain it?

Via the anon CVS, I suppose.

If you have difficulties with that, I could send you the affected
files if Martin tells me what they are.

> 2.	What is the new type that we use to get "unsigned long" for off_t 
> variables and parameters?

It's offset_t, I think.

>  >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.
> 
> Excuse me, didn't you just say we're supporting FAT32?  Shouldn't the 
> types we're introducing be, e.g. F_RDLCK32?

I thought we should use F_RDLCK64 regardless, for compatibility with
other systems; I doubt if F_RDLCK32 will ever be used by some
platform.

> You seem to be saying we add 64-bit types, and only use the
> low-order 32 bits.

Something like that, yes.  I thought about some minimal compatibility,
on the source level, to systems which support true 64-bit file
offsets.