Message-Id: <5.0.1.4.0.20001130210206.0259eb60@pop5.banet.net>
X-Sender: usbanet DOT farley3 AT pop5 DOT banet DOT net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 30 Nov 2000 21:33:32 -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() and flock() patches
Cc: "Mark E." <snowball3 AT bigfoot DOT com>, djgpp-workers AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.1001130101456.23133P-100000@is>
References: <5 DOT 0 DOT 1 DOT 4 DOT 0 DOT 20001129230443 DOT 0259fec0 AT pop5 DOT banet DOT net>
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 10:15 AM 11/30/00 +0200, Eli Zaretskii wrote:
 >
 >On Wed, 29 Nov 2000, Peter J. Farley III wrote:
<Snipped>
 >To me, this means that there are no shared locks, as far as DOS is
 >concerned.  Do you agree, or are you saying something different?

Yes, I agree.

 >> My only concern here would be for applications (like perl) that use 

 >> flock() to issue a LOCK_SH (i.e., F_RDLCK) type of lock, the idea
 >being
 >> to prevent modification by a writer process so a file can be read
 >> without being changed unexpectedly.
 >
 >Will it be good enough for those applications if we treat F_RDLCK as
 >if it were F_WRLCK?

Yes, I believe so.  The only loss is actual shared reading, and any 
program whose coding *depends* on that should probably be doing it in a 
real *ix environment.

 >Btw, Windows 9X will disallow some of the file accesses (when the 
file
 >is open) if another program has it already open.  Perhaps that's what
 >Mark meant with ``read locks on per file basis''?

I don't know.  Mark?

 >> Because of this, I would argue that we do need to keep the 
exception
 >to
 >> the DOS limitation that Mark originally coded, even if it takes a 
bit
 >
 >> more work to confirm it is indeed a "whole file" lock.
 >
 >I don't understand why do we need to confirm that the whole file is
 >being locked, for these cases.

If there are no read locks, and we simulate them with write locks... 
well, maybe not, after all.  If the locks are regional, then another 
process won't be able to change that region, after all.  I see your 
point.  Maybe we can just translate the read locks to write locks and 
be done with it.

 >> If later on, someone else wants to add logic to detect a plain-DOS, 

 >> non-SHARE.EXE environment
 >
 >The detection part is easy: Int 2Fh with AX=1000h will tell you if
 >SHARE is installed (and DTRT on Windows as well, AFAIK).

Well, that's interesting.  Do we then *want* to act as a no-op when 
SHARE is not installed, and always return success?  That still has the 
disadvantage for new coding with erroneous locking logic that it won't 
catch the error(s) until the program is run in a locking environment.
---------------------------------------------------------
Peter J. Farley III (pjfarley AT dorsai DOT org OR
                      pjfarley AT banet DOT net)