Message-Id:	<5.0.2.1.0.20001212231952.025d8780@pop5.banet.net>
X-Sender:	usbanet DOT farley3 AT pop5 DOT banet DOT net
X-Mailer:	QUALCOMM Windows Eudora Version 5.0.2
Date:	Tue, 12 Dec 2000 23:47:04 -0500
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
From:	"Peter J. Farley III" <pjfarley AT banet DOT net>
Subject:	Re: Locking fcntl changes #2
Cc:	djgpp-workers AT delorie DOT com
In-Reply-To:	<Pine.SUN.3.91.1001212113000.24447N-100000@is>
References:	<5 DOT 0 DOT 2 DOT 1 DOT 0 DOT 20001211221616 DOT 00a71e51 AT pop5 DOT banet DOT net>
Mime-Version:	1.0
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

At 11:30 AM 12/12/00 +0200, Eli Zaretskii wrote:
<Snipped>
 >> +/* B4h (180) */ "(MS-DOS 7.0) Lock count has been exceeded",
 >> +/* B4h (180) */ "(NetWare4) Invalid segment number",

I found another one:

+/* 23h (35)  */ "FCB unavailable",
+/* 23h (35)  */ "(PTS-DOS 6.51+, S/DOS 1.0+) Bad FAT",

I have now verified that there are exactly 256 strings for the exterror 
values.

<Snipped>
 >> +      /* If l_len is zero, then the lock is to be set from l_start
 >> +         until the end-of-file. */
 >> +      if (len == 0)
 >> +      {
 >> +        len = filelength(fd) - cur_pos;
 >> +        /* This should probably be an error.  */
 >> +        if (len <= 0)
 >> +          len = 1;
 >> +      }
 >
 >Perhaps the case where filelength returns a negative value (can it?)
 >should indeed return an error, but if filelength returns zero 
(meaning
 >the file is empty), it should succeed, I think, because fcntl allows
 >to lock regions beyond the current EOF.  The question is: does
 >DOS/Windows allow that?  Otherwise, it is not clear to me why the
 >above snippet bumps len to 1.

I researched the question of a zero length to int21/5C.  RBIL is silent 
on the allowed values.  I will have to try setting the current position 
past EOF and then try locking to check the negative case, and setting 
it at EOF and try locking to check the zero case.

 >> +        len = filelength(fd) - cur_pos;
 >> +        /* This should probably be an error.  */
 >> +        if (len <= 0L)
 >> +          len = 1L;
 >
 >Does filelength in the current CVS support FAT32?

I checked filelength, and it returns a long value.  Here is the 
relevant code snippet in "src/libc/posix/sys/stat/filelen.c":

   /* The absolute byte offset returned in DX:AX is the file size. */
   retval = ( (long)regs.x.dx << 16 ) + regs.x.ax;

It looks to me as if this code *will* return negative numbers, since it 
is not an unsigned long, when the current position has been set past 
2^31-1.  I think we will therefore get wrong negative answers for 
positive FAT32 offsets > 2^31-1 and < 2^32-2.

OTOH, for FAT16 file lengths, I do not think this code can return 
negative values, so in the FAT16 section of fcntl it should not be 
possible to get a negative value from filelength.

However, assuming the above code returns the correct bit-value, do you 
think the following use of the filelength function would give the 
desired result?  This would only be coded in the "FAT32" section of 
fcntl, where variable "len" is declared to be an "offset_t" value, and 
thus a "long long":

len = (unsigned long)filelength(fd) - cur_pos;


---------------------------------------------------------
Peter J. Farley III (pjfarley AT dorsai DOT org OR
                      pjfarley AT banet DOT net)

- Raw text -