delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2000/04/04/16:17:59

Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-ID: <99B82AA9708ED0119B55006097125A00363E44@ifk63.mach.uni-karlsruhe.de>
From: Heribert Dahms <heribert_dahms AT icon-gmbh DOT de>
To: "'Mumit Khan'" <khan AT NanoTech DOT Wisc DOT EDU>, cygwin AT sourceware DOT cygnus DOT com
Cc: Christopher Faylor <cgf AT cygnus DOT com>
Subject: RE: Permission denied with makeinfo from texinfo-4.0
Date: Tue, 4 Apr 2000 22:14:46 +0200
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1457.3)

Hi Mumit,

hmm, I don't know Win32 enough, but what about
checking for ERROR_NOACCESS and >32k,
then retry with 0 (or something small) to see if
ERROR_NOACCESS persists? Could be a problem
for e.g. tape access with fixed block sizes...

Bye, Heribert (heribert_dahms AT icon-gmbh DOT de)

> -----Original Message-----
> From:	Mumit Khan [SMTP:khan AT NanoTech DOT Wisc DOT EDU]
> Sent:	Sunday, April 02, 2000 22:59
> To:	cygwin AT sourceware DOT cygnus DOT com
> Cc:	Christopher Faylor
> Subject:	Re: Permission denied with makeinfo from texinfo-4.0
> 
> On Wed, 15 Mar 2000, Chris Faylor wrote:
> 
> > This sounds correct to me.  Passing what is essentially a bogus
> argument
> > for the buffer length is just wrong.  At the very least, it's
> subject to
> > problems if the file size changes while you're reading it.
> Admittedly
> > this is an unusual occurrence but why not program for something like
> this
> > and fail gracefully rather than core dumping?
> > 
> 
> fyi, the makeinfo bug is caused by a (undocumented of course) bug in
> Win32 
> ReadFile routine.
> 
> Here's what David Korn says when it showed up in UWIN as well:
> 
>   Yet some more bizarre undocumented win32 behavior.  If you call the 
>   Win32 ReadFile() function with size greater than 32K, and you are 
>   at the end of file, it does not return successfully with 0 bytes as 
>   you would expect, but fails with ERROR_NOACCESS.
> 
> This should be fixed in the runtime, but I have to find a reliable way
> to detect this (since we have to differentiate between this buggy 
> behaviour and other legitimate causes of ERROR_NOACCESS).
> 
> Regards,
> Mumit
> 
> 
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019