This is the mail archive of the
mailing list for the Cygwin project.
Re: tar hangs on unpacking calcoo_1.3.16.orig.tar
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:
Very helpful, thank you.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple