Date: Fri, 27 Nov 2009 11:57:02 +0100
To: cygwin@cygwin.com
Subject: Re: tar hangs on unpacking calcoo_1.3.16.orig.tar
Message-ID: <20091127105701.GA30132@win.tue.nl>
References: <5a05e0e60911261052w2e60586cxe7a90d02b4cf6e0f@mail.gmail.com> <20091126213025.GA26443@win.tue.nl> <4B0EF59B.90609@cs.umass.edu> <20091127002050.GA27305@win.tue.nl> <20091127005219.GE18148@ednor.casa.cgf.cx> <20091127085608.GW29173@calimero.vinschen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20091127085608.GW29173@calimero.vinschen.de>
User-Agent: Mutt/1.5.18 (2008-05-17)
From: rp@win.tue.nl (Reinier Post)
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

On Fri, Nov 27, 2009 at 09:56:08AM +0100, Corinna Vinschen wrote:
> On Nov 26 19:52, Christopher Faylor wrote:
> > On Fri, Nov 27, 2009 at 01:20:50AM +0100, Reinier Post wrote:
> > >On Thu, Nov 26, 2009 at 04:39:39PM -0500, Eliot Moss wrote:
> > >> I wonder if some process has created the file in
> > >> question and still has it open. Then a call to
> > >> create, and a call to unlink, will both fail.
> > >
> > >But the call to open is failing (the fd returned is -1),
> > >which is why the unlink() is executed in the first place,
> > >and it does *not* fail.
> > >
> > >My vote for Stephan Mueller's suggestion that the 'aux' in the
> > >name is causing the problem - but this still doesn't explaing why
> > >the unlink() claims to succeed (returning 0); the loop within tar
> > >should be changed to deal with this situation in any case.
> > 
> > No, it shouldn't.  We are not going to patch every conceivable
> > program to understand MS-DOS special files.

I am not asking for tar to deal with a special file,
but with a C source code file that happens to be named aux.c.
I'm not even asking for it to write that file, merely not to go
into an infinite loop.  I know tar can easily hang on certain input
(e.g. /dev/zero) but I think this particular behavior is not something
users can be expected to work around preventively - a bug.
(I found it by running a script that invokes tar 63000 times overnight,
 and tar is often used in such non-interactive contexts.)

Can't this be handled at the system call level?
After all it's not the tar source code but unlink()'s return code
that seems to cause the problem.

> > This won't be a problem with Cygwin 1.7.  If you want a fix change
> > to that.

Thank you, I wasn't aware of 1.7.

> Just as a sidenote a pointer to the new User's Guide:
> http://cygwin.com/1.7/cygwin-ug-net/using-specialnames.html#pathnames-dosdevices
> 
> Corinna

Very helpful, thank you.

-- 
Reinier Post

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple