Date:	Wed, 29 Nov 2000 10:14:18 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Mark E." <snowball3 AT bigfoot DOT com>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Locking fcntl() and flock() patches
In-Reply-To:	<3A243B9A.31778.2984396@localhost>
Message-ID:	<Pine.SUN.3.91.1001129101403.10519B-100000@is>
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

On Tue, 28 Nov 2000, Mark E. wrote:

> Also, I believe I wrote the mysterious comment (from my original code):
>       /* DOS/Windows only support read locks on a per-file basis,
>          so any attempted use of a read lock is an error.  */
> 
> based on some document, possibly the RBIL. Perhaps a better way to have put 
> it would have been:
>   /* DOS/Windows 9x do not support read locks, so any attempted use is an 
> error.  */

This is indeed what I glean from RBIL: read (i.e., shared) locks are
simply unsupported.  I wonder how should we translate this into our
implementation.  Perhaps simply let SHARE/VSHARE do its thing, and if
the fail, return with a failure?

> I can go along with the extra file handle checks, but I don't really think 
> they're neccessary because the early _get_dev_info test does the job of 
> filtering out bad handles.

That's true, but I'm worried by possible changes of the code in the
future, including the case that someone will rip the internal
functions out of fcntl.c and make them public (like already happened
with mntent.c).

- Raw text -