Date: Sun, 5 Aug 2001 10:14:46 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Andrew Cottrell <acottrel AT ihug DOT com DOT au>
cc: Charles Sandmann <sandmann AT clio DOT rice DOT edu>, djgpp-workers AT delorie DOT com
Subject: Re: Windows 2000 /dev/null permission query
In-Reply-To: <00b601c11d4e$1fb7ac30$0a02a8c0@acceleron>
Message-ID: <Pine.SUN.3.91.1010805101426.10001H-100000@is>
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 Sun, 5 Aug 2001, Andrew Cottrell wrote:

> > > In particular, open on /dev/null fails using O_TRUNC
> >
> > In this case we attempt a write to the device of 0 bytes.  This
> > write fails with dos error code of 5 = Access denied.
> >
> > It appears to me the easiest fix for this is in open.c, which has a
> > section which looks like:
> >
> >   if ((oflag & O_TRUNC) && !should_create)
> >     if (_write(fd, 0, 0) < 0)
> >       return -1;
> >
> > would be to ignore the return code from _write in this case:
> >
> >   if ((oflag & O_TRUNC) && !should_create)
> >     _write(fd, 0, 0);
> >
> > Comments?  Can anyone think of a real case we would expect a write of 0
> > bytes to fail and we would want that to be fatal to the open?  The
> > handle is open and allocated...
> 
> Charles you are spot on with this one.
> 
> Tested this with a small test app that is effectively one call to
> system("djecho foo >nul\0") and the patch above fixes the problem. I will
> try this patch on LIBC and re-build packages again and re-test.

I'd prefer to understand this problem a bit more.  For starters, does
it affect NUL alone, or any other character device emulated by NTVDM?
To find out, try redirecting to PRN, LPT1, AUX, and CON.

If this only affects character devices, we can test the handle for
being connected to a character device, and _then_ ignore the error.  I
don't think we should ignore it for disk files: that would be a subtle
misfeature.