* tar: Child died with signal 13
@ 2002-02-26 2:54 Volker Quetschke
2002-02-26 6:14 ` Eugene Rosenzweig
0 siblings, 1 reply; 8+ messages in thread
From: Volker Quetschke @ 2002-02-26 2:54 UTC (permalink / raw)
To: cygwin
Hi,
recently I found a problem when I try to untar some tar.gz archives
under cygwin. The tar.gz at this link is ca. 1,5kb
http://www.scytek.de/expat.pat.tar.gz .
It is just one example, it is taken from OpenOffice641C.
On my Windows 2K machine, cygwin updatet a few minutes ago, I get:
Administrator@LISI ~/tartest
$ tar -tzf expat.pat.tar.gz
pat/
pat/xmlparse/
pat/xmlparse/hashtable.h.pat
pat/xmlparse/xmlparse.h.pat
pat/xmltok/
tar: Child died with signal 13
tar: Error exit delayed from previous errors
Administrator@LISI ~/tartest
$ la
total 6
dr-xr-xr-x 2 Administ Kein 0 Feb 26 10:02 .
drwxr-xr-x 6 Administ Kein 4096 Feb 26 10:02 ..
-r-xr-xr-x 1 Administ Kein 1435 Sep 20 2000 expat.pat.tar.gz
I get this error in both cases, with CYGWIN=ntsec tty and CYGWIN=tty.
I also get this error on Cygwin on our Windows 2K server, but there I
can't change the environement ;-)
If I do an gunzip first, and then a tar -tf foo.tar I get no error.
I also don't get an error doing the tar -tzf on cygwin on Windows98SE
or Linux.
Only few *.tar.gz files have this problem, but some have. I have three
more examples, but they are not so short as the one mentioned above.
Any ideas?
Volker
--
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Child died with signal 13
2002-02-26 2:54 tar: Child died with signal 13 Volker Quetschke
@ 2002-02-26 6:14 ` Eugene Rosenzweig
2002-02-27 10:41 ` Volker Quetschke
2002-02-28 7:42 ` Randall R Schulz
0 siblings, 2 replies; 8+ messages in thread
From: Eugene Rosenzweig @ 2002-02-26 6:14 UTC (permalink / raw)
To: Volker Quetschke, cygwin
Hmm, it worked for me. I assume out of the documentation that tar will spawn
gzip -d filename and pipe it into itself. So, if 13 is the system error from
tar, which is EACCES, permission denied so maybe there is a problem
accessing the file? The listing shows that file is owned by Administ(rator?)
and prompt says Administrator so it seems correct but if you substitute
filename for nonexistent one then you get
tar: Child died with signal 2 <-- 2 being 'file not found' error
so it seems that there is a problem with permissions?
Eugene.
----- Original Message -----
From: "Volker Quetschke" <quetschke@scytek.de>
To: <cygwin@cygwin.com>
Sent: Tuesday, February 26, 2002 9:38 PM
Subject: tar: Child died with signal 13
> Hi,
>
> recently I found a problem when I try to untar some tar.gz archives
> under cygwin. The tar.gz at this link is ca. 1,5kb
> http://www.scytek.de/expat.pat.tar.gz .
> It is just one example, it is taken from OpenOffice641C.
>
> On my Windows 2K machine, cygwin updatet a few minutes ago, I get:
>
> Administrator@LISI ~/tartest
> $ tar -tzf expat.pat.tar.gz
> pat/
> pat/xmlparse/
> pat/xmlparse/hashtable.h.pat
> pat/xmlparse/xmlparse.h.pat
> pat/xmltok/
> tar: Child died with signal 13
> tar: Error exit delayed from previous errors
>
> Administrator@LISI ~/tartest
> $ la
> total 6
> dr-xr-xr-x 2 Administ Kein 0 Feb 26 10:02 .
> drwxr-xr-x 6 Administ Kein 4096 Feb 26 10:02 ..
> -r-xr-xr-x 1 Administ Kein 1435 Sep 20 2000 expat.pat.tar.gz
>
> I get this error in both cases, with CYGWIN=ntsec tty and CYGWIN=tty.
>
> I also get this error on Cygwin on our Windows 2K server, but there I
> can't change the environement ;-)
>
> If I do an gunzip first, and then a tar -tf foo.tar I get no error.
>
> I also don't get an error doing the tar -tzf on cygwin on Windows98SE
> or Linux.
>
> Only few *.tar.gz files have this problem, but some have. I have three
> more examples, but they are not so short as the one mentioned above.
>
> Any ideas?
>
> Volker
> --
>
>
> --
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting: http://cygwin.com/bugs.html
> Documentation: http://cygwin.com/docs.html
> FAQ: http://cygwin.com/faq/
>
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Child died with signal 13
2002-02-26 6:14 ` Eugene Rosenzweig
@ 2002-02-27 10:41 ` Volker Quetschke
2002-03-04 2:06 ` Max Bowsher
2002-02-28 7:42 ` Randall R Schulz
1 sibling, 1 reply; 8+ messages in thread
From: Volker Quetschke @ 2002-02-27 10:41 UTC (permalink / raw)
To: cygwin
Hi,
Eugene Rosenzweig wrote:
> Hmm, it worked for me. I assume out of the documentation that tar will spawn
> gzip -d filename and pipe it into itself. So, if 13 is the system error from
> tar, which is EACCES, permission denied so maybe there is a problem
> accessing the file? The listing shows that file is owned by Administ(rator?)
> and prompt says Administrator so it seems correct but if you substitute
> filename for nonexistent one then you get
> tar: Child died with signal 2 <-- 2 being 'file not found' error
> so it seems that there is a problem with permissions?
I tried the command also without NTSEC, then file permissions shouldn't
be a problem.
I also tried a third Windows 2k Computer with:
>>recently I found a problem when I try to untar some tar.gz archives
>>under cygwin. The tar.gz at this link is ca. 1,5kb
>> http://www.scytek.de/expat.pat.tar.gz .
>>It is just one example, it is taken from OpenOffice641C.
This time I used also a text mount, same error, see below. (I also
attached cygcheck -s) As I said, "tar -tzf .." with this file works from
windows 98 (cygwin) and linux.
q@LP16 /txt
$ tar -tzf expat.pat.tar.gz
pat/
pat/xmlparse/
pat/xmlparse/hashtable.h.pat
pat/xmlparse/xmlparse.h.pat
pat/xmltok/
tar: Child died with signal 13
tar: Error exit delayed from previous errors
q@LP16 /txt
$ gunzip -c expat.pat.tar.gz | tar -tf -
pat/
pat/xmlparse/
pat/xmlparse/hashtable.h.pat
pat/xmlparse/xmlparse.h.pat
pat/xmltok/
q@LP16 /txt
$ ls -al
total 18
drwxrwxrwx 2 admins dbenutze 0 Feb 27 17:47 .
drwxr-xr-x 13 admins admins 16384 Feb 7 12:47 ..
-rwxrwxrwx 1 admins dbenutze 1435 Feb 27 17:33 expat.pat.tar.gz
(I also changed the owner of expat... to q dbenutzer, changed nothing)
Is there really nobody with this problem??????
Thanks
Volker
q@LP16 /txt
$ cygcheck -s
Cygwin Win95/NT Configuration Diagnostics
Current System Time: Wed Feb 27 18:51:29 2002
Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 2
Path:
d:\cygwin\usr\local\bin
d:\cygwin\bin
d:\cygwin\bin
c:\WINNT\system32
c:\WINNT
c:\WINNT\System32\Wbem
d:\bin
d:\cygwin\bin
c:\programme\matlab6p1\bin\win32
SysDir: C:\WINNT\System32
WinDir: C:\WINNT
CYGWIN = `tty ntsec'
HOME = `d:\cygwin\home\q'
MAKE_MODE = `unix'
PWD = `/txt'
USER = `q'
Use `-r' to scan registry
a: fd N/A N/A
c: hd NTFS 9452Mb 35% CP CS UN PA FC Win2K
d: hd NTFS 9585Mb 80% CP CS UN PA FC QE1
e: hd NTFS 9585Mb 54% CP CS UN PA FC QE2
f: cd N/A N/A
g: fd N/A N/A
d:\txt /txt user textmode
. /cygdrive user binmode,noumount
d:/cygwin / system binmode
d:/cygwin/bin /usr/bin system binmode
d:/cygwin/lib /usr/lib system binmode
Found: d:\cygwin\bin\bash.exe
Found: d:\cygwin\bin\cat.exe
Found: d:\cygwin\bin\cpp.exe
Found: d:\cygwin\bin\find.exe
Found: d:\cygwin\bin\gcc.exe
Found: d:\cygwin\bin\gdb.exe
Found: d:\cygwin\bin\ld.exe
Found: d:\cygwin\bin\ls.exe
Found: d:\cygwin\bin\make.exe
Found: d:\cygwin\bin\sh.exe
56k 2000/12/03 d:\cygwin\bin\cygbz21.0.dll
621k 2002/01/16 d:\cygwin\bin\cygcrypto.dll
107k 2002/01/23 d:\cygwin\bin\cygcurl-2.dll
45k 2001/04/25 d:\cygwin\bin\cygform5.dll
35k 2002/01/09 d:\cygwin\bin\cygform6.dll
18k 2000/10/23 d:\cygwin\bin\cyggdbm.dll
22k 2001/12/13 d:\cygwin\bin\cygintl-1.dll
21k 2001/06/20 d:\cygwin\bin\cygintl.dll
81k 2001/10/20 d:\cygwin\bin\cygitcl30.dll
35k 2001/10/20 d:\cygwin\bin\cygitk30.dll
45k 2002/02/08 d:\cygwin\bin\cygjbig1.dll
119k 2002/02/09 d:\cygwin\bin\cygjpeg6b.dll
26k 2001/04/25 d:\cygwin\bin\cygmenu5.dll
20k 2002/01/09 d:\cygwin\bin\cygmenu6.dll
156k 2001/04/25 d:\cygwin\bin\cygncurses++5.dll
175k 2002/01/09 d:\cygwin\bin\cygncurses++6.dll
226k 2001/04/25 d:\cygwin\bin\cygncurses5.dll
202k 2002/01/09 d:\cygwin\bin\cygncurses6.dll
15k 2001/04/25 d:\cygwin\bin\cygpanel5.dll
12k 2002/01/09 d:\cygwin\bin\cygpanel6.dll
40k 2001/11/21 d:\cygwin\bin\cygpcre.dll
39k 2001/11/21 d:\cygwin\bin\cygpcreposix.dll
170k 2002/01/21 d:\cygwin\bin\cygpng2.dll
66k 2001/11/20 d:\cygwin\bin\cygregex.dll
156k 2002/01/16 d:\cygwin\bin\cygssl.dll
390k 2001/10/20 d:\cygwin\bin\cygtcl80.dll
5k 2001/10/20 d:\cygwin\bin\cygtclpip80.dll
10k 2001/10/20 d:\cygwin\bin\cygtclreg80.dll
253k 2002/02/10 d:\cygwin\bin\cygtiff3.dll
623k 2001/10/20 d:\cygwin\bin\cygtk80.dll
41k 2002/01/20 d:\cygwin\bin\cygXpm-noX4.dll
46k 2002/01/20 d:\cygwin\bin\cygXpm-X4.dll
50k 2002/01/20 d:\cygwin\bin\cygz.dll
751k 2002/01/21 d:\cygwin\bin\cygwin1.dll
Cygwin DLL version info:
DLL version: 1.3.9
DLL epoch: 19
DLL bad signal mask: 19005
DLL old termios: 5
DLL malloc env: 28
API major: 0
API minor: 51
Shared data: 3
DLL identifier: cygwin1
Mount registry: 2
Cygnus registry name: Cygnus Solutions
Cygwin registry name: Cygwin
Program options name: Program Options
Cygwin mount registry name: mounts v2
Cygdrive flags: cygdrive flags
Cygdrive prefix: cygdrive prefix
Cygdrive default prefix:
Build date: Mon Jan 21 12:48:41 EST 2002
Shared id: cygwin1S3
Cygwin Package Information
Package Version
ash 20020131-1
autoconf 2.52a-1
autoconf-devel 2.52-4
autoconf-stable 2.13-4
automake 1.5b-1
automake-devel 1.5-5
automake-stable 1.4p5-5
bash 2.05a-3
bc 1.06-1
binutils 20011002-1
bison 1.33-1
byacc 1.9-1
bzip2 1.0.1-6
clear 1.0
cpio 2.4.2
cron 3.0.1-5
crypt 1.0-1
ctags 5.2-1
curl 7.9.3-1
cvs 1.11.0-1
cygrunsrv 0.94-2
cygutils 0.9.8-1
cygwin 1.3.9-1
dejagnu 20010117-1
diff 0.0
ed 0.2-1
expect 20010117-1
figlet 2.2-1
file 3.37-1
fileutils 4.1-1
findutils 4.1
flex 2.5.4-1
gawk 3.0.4-1
gcc 2.95.3-5
gdb 20010428-3
gdbm 1.8.0-3
gettext 0.10.40-1
ghostscript 6.51-3
gperf 0.0
grep 2.4.2-1
groff 1.17.2-1
gzip 1.3.2-1
indent 2.2.7-2
inetutils 1.3.2-17
irc 20010101-1
jbigkit 1.2-6
jpeg 6b-7
less 358-3
libintl 0.10.38-3
libintl1 0.10.40-1
libncurses5 5.2-1
libncurses6 5.2-8
libpng 1.0.12-1
libpng2 1.0.12-1
libreadline4 4.1-2
libreadline5 4.2a-1
login 1.4-3
lynx 2.8.4-1
m4 0.0
make 3.79.1-5
man 1.5g-2
mingw 20010917-1
mingw-runtime 1.2-1
mktemp 1.4-1
mt 2.0.1-1
mutt 1.2.5i-6
nano 1.0.7-1
ncftp 3.0.2-2
ncurses 5.2-8
newlib-man 20001118-1
opengl 1.1.0-5
openssh 3.0.2p1-5
openssl 0.9.6c-3
patch 2.5-3
pcre 3.7-1
perl 5.6.1-2
popt 1.6.2-1
postgresql 7.1.3-2
python 2.2-1
rcs 5.7-2
readline 4.2a-1
regex 4.4-2
rsync 2.5.2-1
rxvt 2.7.2-9
sed 3.02-1
sh-utils 2.0-2
sharutils 4.2.1-2
shutdown 1.2-2
squid 2.4-STABLE20010508
ssmtp 2.38.7-3
tar 1.13.19-1
tcltk 20001125-1
tcsh 6.11.00-4
termcap 20010825-1
terminfo 5.2-1
tetex-beta 20001218-1
texinfo 4.0-5
textutils 2.0.16-1
tiff 3.5.7-1
time 1.7-1
unzip 5.41-1
vim 6.0.93-1
w32api 1.2-1
wget 1.8.1-1
which 1.5-1
xpm-nox 4.2.0-1
zip 2.3-1
zlib 1.1.3-7
Use -h to see help about each section
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Child died with signal 13
2002-02-26 6:14 ` Eugene Rosenzweig
2002-02-27 10:41 ` Volker Quetschke
@ 2002-02-28 7:42 ` Randall R Schulz
2002-03-01 6:47 ` Volker Quetschke
1 sibling, 1 reply; 8+ messages in thread
From: Randall R Schulz @ 2002-02-28 7:42 UTC (permalink / raw)
To: Eugene Rosenzweig, Volker Quetschke, cygwin
Eugene,
Signal numbers and errno codes (and process status codes) are distinct.
Process status codes to incorporate the signal number when a signal caused
the death of the process.
Signal 13 is SIGPIPE: Write to a pipe with no process there to read the
data. In your context, this means the tar process has closed the pipe
because it has concluded there is no more data to be retrieved from the
gunzip sub-process it started in response to the 'z' option. If tar didn't
do this, it would have to read all the gunzip-ed data. If it didn't either
close the pipe (leading to the signal) or read the data, the child would
just block and those processes would stall (at least until you or some
other external action killed the tar + gunzip process group).
Signal 2 is SIGINT, the signal that results when you type a ^C.
Interactive shells suppress messages about certain signals causing process
termination. In particular, SIGPIPE and SIGINT terminations are not
reported as such by BASH. Tar is not making these exceptions.
Randall Schulz
Mountain View, CA USA
At 05:51 2002-02-26, Eugene Rosenzweig wrote:
>Hmm, it worked for me. I assume out of the documentation that tar will
>spawn gzip -d filename and pipe it into itself. So, if 13 is the system
>error from tar, which is EACCES, permission denied so maybe there is a
>problem accessing the file? The listing shows that file is owned by
>Administ(rator?) and prompt says Administrator so it seems correct but if
>you substitute filename for nonexistent one then you get tar: Child died
>with signal 2 <-- 2 being 'file not found' error so it seems that there is
>a problem with permissions?
>
>Eugene.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Child died with signal 13
2002-02-28 7:42 ` Randall R Schulz
@ 2002-03-01 6:47 ` Volker Quetschke
2002-03-01 7:29 ` Randall R Schulz
0 siblings, 1 reply; 8+ messages in thread
From: Volker Quetschke @ 2002-03-01 6:47 UTC (permalink / raw)
To: cygwin
Hi,
> Signal numbers and errno codes (and process status codes) are distinct.
> Process status codes to incorporate the signal number when a signal
> caused the death of the process.
>
> Signal 13 is SIGPIPE: Write to a pipe with no process there to read the
> data. In your context, this means the tar process has closed the pipe
> because it has concluded there is no more data to be retrieved from the
> gunzip sub-process it started in response to the 'z' option. If tar
> didn't do this, it would have to read all the gunzip-ed data. If it
> didn't either close the pipe (leading to the signal) or read the data,
> the child would just block and those processes would stall (at least
> until you or some other external action killed the tar + gunzip process
> group).
I have no idea where the problem is, but I got one ME TOO which
confirmed that not only I have the problem with tar saying: "Child died
with signal 13". So, Windows 2000, Windows 2000 Server and Windows NT4
SP6 have the problem, Windows 98 and any other *nix machine I testet
have not. I think it's cygwin related!
Because I have no idea where to look in the cygwin sources I decided the
only way to help the developers *YOU* is to build a more simple
testcase. Here it comes:
--------------------------
Administrator@LISI ~/qqq
$ tar -czvf a.tar.gz a/
a/
a/error.txt
Administrator@LISI ~/qqq
$ tar -tzvf a.tar.gz
drwxrwxrwx Administratoren/Kein 0 2002-03-01 14:22:18 a/
-rwxrwxrwx Administratoren/Kein 8193 2002-03-01 14:21:15 a/error.txt
tar: Child died with signal 13
tar: Error exit delayed from previous errors
Administrator@LISI ~/qqq
$ tar -cvf a.tar a/
a/
a/error.txt
Administrator@LISI ~/qqq
$ ll
total 21
drwxrwxrwx 2 Administ Kein 0 Mar 1 14:22 a
-rw-rw-rw- 1 Administ Kein 20480 Mar 1 14:26 a.tar
-rw-rw-rw- 1 Administ Kein 299 Mar 1 14:23 a.tar.gz
--------------------------
You can get a.tar.gz at: http://www.scytek.de/a.tar.gz . The problem is
related to the length of the tar file. If you delete one charakter in
error.txt, and its length drops to 8192 then the length of the tar file
drops to 10240 bytes and you don't get the "tar: Child died with signal
13". I didn't test how many bytes one has to add to let the error vanish.
Hope this makes it easy to find the problem.
Volker
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Child died with signal 13
2002-03-01 6:47 ` Volker Quetschke
@ 2002-03-01 7:29 ` Randall R Schulz
2002-03-01 8:29 ` Volker Quetschke
0 siblings, 1 reply; 8+ messages in thread
From: Randall R Schulz @ 2002-03-01 7:29 UTC (permalink / raw)
To: Volker Quetschke, cygwin
Volker,
I don't think there's a problem here, actually.
I occasionally get these diagnostics, too, but there's never a problem
extracting the files from the archive. Apparently tar knows it's seen the
last TOC entry and closes the pipe from the gunzip sub-process. Then it
waits for that process to exit. Since gunzip doesn't explicitly handle
SIGPIPE and terminate gracefully, its death at the hand of the SIGPIPE is
reported to tar and tar then dutifully reports it to you.
I retrieved your test file and got the same result as you. Aside from the
diagnostic, which I got for this file and get for others sometimes, I've
had no trouble with tar.
I can't tell for sure if "a/error.txt" was retrieved accurately, so here's
the checksum for that file as extracted on my system:
% sum a/error.txt
28232 9
However, by using tar's "-i" option:
-i, --ignore-zeros ignore zeroed blocks in archive (means EOF)
the error was suppressed. I'm guessing it forces tar to read all the data
in the uncompressed input file instead of quitting early.
My recommendation is that you ignore this error. If you're concerned about
the data integrity, you can use the "-t --test" option to gunzip to check
the data in your gzip-ed files before submitting them to tar.
Randall Schulz
Mountain View, CA USA
At 06:46 2002-03-01, Volker Quetschke wrote:
>Hi,
>
>>Signal numbers and errno codes (and process status codes) are distinct.
>>Process status codes to incorporate the signal number when a signal
>>caused the death of the process.
>>
>>Signal 13 is SIGPIPE: Write to a pipe with no process there to read the
>>data. In your context, this means the tar process has closed the pipe
>>because it has concluded there is no more data to be retrieved from the
>>gunzip sub-process it started in response to the 'z' option. If tar
>>didn't do this, it would have to read all the gunzip-ed data. If it
>>didn't either close the pipe (leading to the signal) or read the data,
>>the child would just block and those processes would stall (at least
>>until you or some other external action killed the tar + gunzip process group).
>
>
>I have no idea where the problem is, but I got one ME TOO which confirmed
>that not only I have the problem with tar saying: "Child died with signal
>13". So, Windows 2000, Windows 2000 Server and Windows NT4 SP6 have the
>problem, Windows 98 and any other *nix machine I testet have not. I think
>it's cygwin related!
>
>Because I have no idea where to look in the cygwin sources I decided the
>only way to help the developers *YOU* is to build a more simple testcase.
>Here it comes:
>
>--------------------------
>Administrator@LISI ~/qqq
>$ tar -czvf a.tar.gz a/
>a/
>a/error.txt
>
>Administrator@LISI ~/qqq
>$ tar -tzvf a.tar.gz
>drwxrwxrwx Administratoren/Kein 0 2002-03-01 14:22:18 a/
>-rwxrwxrwx Administratoren/Kein 8193 2002-03-01 14:21:15 a/error.txt
>tar: Child died with signal 13
>tar: Error exit delayed from previous errors
>
>Administrator@LISI ~/qqq
>$ tar -cvf a.tar a/
>a/
>a/error.txt
>
>Administrator@LISI ~/qqq
>$ ll
>total 21
>drwxrwxrwx 2 Administ Kein 0 Mar 1 14:22 a
>-rw-rw-rw- 1 Administ Kein 20480 Mar 1 14:26 a.tar
>-rw-rw-rw- 1 Administ Kein 299 Mar 1 14:23 a.tar.gz
>--------------------------
>
>You can get a.tar.gz at: http://www.scytek.de/a.tar.gz . The problem is
>related to the length of the tar file. If you delete one charakter in
>error.txt, and its length drops to 8192 then the length of the tar file
>drops to 10240 bytes and you don't get the "tar: Child died with signal
>13". I didn't test how many bytes one has to add to let the error vanish.
>
>Hope this makes it easy to find the problem.
>
> Volker
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Child died with signal 13
2002-03-01 7:29 ` Randall R Schulz
@ 2002-03-01 8:29 ` Volker Quetschke
0 siblings, 0 replies; 8+ messages in thread
From: Volker Quetschke @ 2002-03-01 8:29 UTC (permalink / raw)
To: cygwin
Randall,
thanks for having a look at this topic.
> I don't think there's a problem here, actually.
>
> I occasionally get these diagnostics, too, but there's never a problem
> extracting the files from the archive. Apparently tar knows it's seen
> the last TOC entry and closes the pipe from the gunzip sub-process. Then
> it waits for that process to exit. Since gunzip doesn't explicitly
> handle SIGPIPE and terminate gracefully, its death at the hand of the
> SIGPIPE is reported to tar and tar then dutifully reports it to you.
>
> I retrieved your test file and got the same result as you. Aside from
> the diagnostic, which I got for this file and get for others sometimes,
> I've had no trouble with tar.
Hmmm, I just don't like (false) error messages :-), but you are right
tar works correctly. I was just wondering about the error on NT and not
on other systems.
> I can't tell for sure if "a/error.txt" was retrieved accurately, so
> here's the checksum for that file as extracted on my system:
>
> % sum a/error.txt
> 28232 9
Yes it's the checksum of the original file.
> However, by using tar's "-i" option:
>
> -i, --ignore-zeros ignore zeroed blocks in archive (means EOF)
>
> the error was suppressed. I'm guessing it forces tar to read all the
> data in the uncompressed input file instead of quitting early.
Thanks for this hint.
Bye
Volker
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Child died with signal 13
2002-02-27 10:41 ` Volker Quetschke
@ 2002-03-04 2:06 ` Max Bowsher
0 siblings, 0 replies; 8+ messages in thread
From: Max Bowsher @ 2002-03-04 2:06 UTC (permalink / raw)
To: cygwin
<snip stuff about tar dying when asked to use gzip as a filter internally
> Is there really nobody with this problem??????
>
> Thanks
>
> Volker
Yes, I have experienced this intermittently. Unfortunately, it has never
been reproducable enough to investigate.
I only remeber seeing signal 11's, by the way.
Max.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-03-04 10:06 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-02-26 2:54 tar: Child died with signal 13 Volker Quetschke
2002-02-26 6:14 ` Eugene Rosenzweig
2002-02-27 10:41 ` Volker Quetschke
2002-03-04 2:06 ` Max Bowsher
2002-02-28 7:42 ` Randall R Schulz
2002-03-01 6:47 ` Volker Quetschke
2002-03-01 7:29 ` Randall R Schulz
2002-03-01 8:29 ` Volker Quetschke
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).