From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10108051749.AA17568@clio.rice.edu>
Subject: Re: Windows 2000 /dev/null permission query
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Sun, 5 Aug 2001 12:49:25 -0500 (CDT)
Cc: acottrel AT ihug DOT com DOT au (Andrew Cottrell), djgpp-workers AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.1010805101426.10001H-100000@is> from "Eli Zaretskii" at Aug 05, 2001 10:14:46 AM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

> > > It appears to me the easiest fix for this is in open.c, ...
> > > 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...
> 
> 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.

It also fails for "con" which was easy to test.  
It did not fail for "prn", "aux", or "com1"

> 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.

If a write of 0 bytes to a disk file fails (why/how would this ever happen?), 
then the first write the user performs should also fail?

With the current code, if the write of 0 bytes fails, shouldn't we at least 
close the handle instead of just returning?

I think this is a case where removing the check fixes the problem without
having to make the code bigger, slower and more complex (and prone to future 
issues) without any known downside.