Date: Wed, 29 Nov 2000 10:14:18 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: "Mark E." cc: djgpp-workers AT delorie DOT com Subject: Re: Locking fcntl() and flock() patches In-Reply-To: <3A243B9A.31778.2984396@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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).