delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/09/16/03:17:39

Date: Sun, 16 Sep 2001 09:12:59 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc: djgpp-workers AT delorie DOT com, Esa A E Peuha <peuha AT cc DOT helsinki DOT fi>
Subject: Re: A new W2K problem: djtar
In-Reply-To: <10109152029.AA13731@clio.rice.edu>
Message-ID: <Pine.SUN.3.91.1010916091216.7026B-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 Sat, 15 Sep 2001, Charles Sandmann wrote:

> > from epunzip.c:
> > 	epoutfile = open("/dev/null",
> > 			 O_WRONLY | O_BINARY | O_CREAT | O_EXCL,
> > 
> > This fails inside `open', since it sees O_CREAT, decides that the file
> > should be created anew, calls __file_exists to see if /dev/null
> > exists, and since __file_exists returns non-zero, `open' fails.
> > 
> > This seems like a bug in epunzip.c, doesn't it?  Why should it insist
> > on creating /dev/null?
> > 
> > OTOH, I don't understand how does it work on other platforms?  Oh, I
> > see: __file_exists fails for devices on every other platform.  Does
> > this form of `open' work on GNU/Linux?
> 
> This open does not work on other Unix systems I tested.  The O_CREAT
> isn't the problem it the O_EXCL - which fails if the specified file
> exists.  This is a bug in epunzip (2 places).  I don't think we 
> should need O_CREAT either, but O_EXCL is the problem.

I agree.

Esa, is there any reason why I shouldn't remove O_EXCL from those two
calls in epunzip.c?

- Raw text -


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