[BusyBox] Race condition with tar zxf

[Robert Kaiser]

On Die, 27 Mär 2001 you wrote:
> Robert Kaiser wrote:
 > 
> > The JFFS filesystem is relatively slow on writes, so, apparently
> > what happens is that the unzip process that busybox tar forks off
> > terminates before the tar process has begun processing the last
> > chunk of data. The termination of unzip triggers the signal handler
> > ("child_died()") which in turn causes tar to exit prematurely
> > (i.e. before it has completely written the last file).
> >  ...
> > However, I'm still wondering why we need this signal fuss at all.
> > I would expect that read() returns zero (indicating EOF) when the
> > gzip process at the other end of the pipe terminates and the pipe
> > is empty, so, not setting up a signal handler at all should work
> > fine. I have tried this (see the second attached "patch-no-sighand")
> > and it solved my problem just as well. Question is: have I broken
> > anything ?
> > 
> Ive been working on some dpkg applets, which are .ar files that contain
> tar.gz files inside, in this case the .tar.gz is in the middle of other
> data, so if read is allowed to continue it will read past the end of the
> .tar.gz and then encounter invalid data (the start of the next file) and
> rreport an error.

Hmm, I don't quite see how any of the two patches I proposed could
affect you in this situation. 

The unzip process would be the one to read past the end of the .tar.gz
and I have not changed any of the unzip code.

[BTW: I'm not familiar wih the gzip algorithm, but I always thought that it
does some sort of framing, so it should be able to tell when it's input stream
is finished, without having to rely on reading until EOF.]

> 
> The gz_open code is mostly taken from tar anyway, i think the forking
> code for accessing a decompressed stream of data really should go in the
> gunzip.c rather than in applets prior to calling unzip.

Agreed. But where do you want put the SIGCHLD handler that is currently in tar ?
If you think that it is really necessary (which I'm still not convinced of),
please make sure that it does not just unconditionally exit the parent process
(see the first of my patches).

Cheers

Rob



----------------------------------------------------------------
Robert Kaiser                         email: rkaiser at sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14                    phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10