Message-Id: <5.0.1.4.0.20001201234954.0347fec0@pop5.banet.net> X-Sender: usbanet DOT farley3 AT pop5 DOT banet DOT net X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Sat, 02 Dec 2000 00:30:41 -0500 To: "Eli Zaretskii" From: "Peter J. Farley III" Subject: Re: Locking fcntl() and flock() patches Cc: Martin Stromberg , djgpp-workers AT delorie DOT com In-Reply-To: <4331-Fri01Dec2000184658+0200-eliz@is.elta.co.il> References: <200012011435 DOT PAA09759 AT lws256 DOT lu DOT erisoft DOT se> <200012011435 DOT PAA09759 AT lws256 DOT lu DOT erisoft DOT se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 At 06:46 PM 12/1/00 +0200, Eli Zaretskii wrote: >> From: Martin Stromberg >> Date: Fri, 1 Dec 2000 15:35:13 +0100 (MET) >> >> F_GETLK64 Equivalent to F_GETLK, but takes a struct >> flock64 argument rather than a struct flock >> argument. > >Thanks, Martin! > >Peter, I think this explains everything. If you don't mind writing >yet another bunch of "case F_..." clauses and adding the necessary >code to support FAT32, it would be mighty nice ;-). 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. I'm also not real clear on how the _dos_lock and _dos_unlock functions would have to be modified to pass 64-bit values to int21/5c. From RBIL 61, the parameters to int21/5c are: 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. Am I not seeing something? And the code in _dos_lock (and unlock) also implies only 32 bits each: r.x.cx = _offset >> 16; r.x.dx = _offset; r.x.si = _length >> 16; r.x.di = _length; Where do we provide the other 32 bits for each parameter to INT21? I will proceed with the F_RDLCK -> F->WRLCK translation, along with the documentation updates already discussed, but I'd like a whole lot more detailed guidance before I can agree to 64-bitness enhancements. --------------------------------------------------------- Peter J. Farley III (pjfarley AT dorsai DOT org OR pjfarley AT banet DOT net)