Formaline might stop build because of errors reported by tar

Issue #69 closed
Frank Löffler created an issue

Beginning with version 1.16 of gnu tar: <quote> After creating an archive, tar exits with code 1 if some files were changed while being read. Previous versions exited with code 2 (fatal error), and only if some files were truncated while being archived. </quote>

Even reading a file (as is done when compiling it in parallel) will change it in tar's view, because this changes the atime of the file. There does not seem to be an option which turns this new behavior off. Instead it is recommended to check the exit code of tar which is 0: if everything went ok 1: if files changed while being read/written 2: if some other error occurs.

This means that Formaline should treat an exit code of 1 in tar as 'ok', while currently it aborts the build. However, this is safely true only for gnu tar. For example the version of tar on the 'pelican' system states: <quote> 0 Successful completion.

0 An error occurred. </quote> This is too vague to decide if ignoring an exit code of 1 can also here be ignored. File changes are a kind of error - of a kind one might be able to ignore. The documentation of this old version of tar doesn't mention which values are actually used for which errors though.

Somewhere else I found [http://aplawrence.com/Bofcusm/2073.html this]: <quote> 0 - success 1 - bad directory tree, failed to extract a requested file, input file same as output file, failed to open input file, could not create link, link table malloc failure 2 - internationalization error that should never occur, checksum error 5 - checksum error 9 (EBADF) - error reading /etc/default/tar, misplaced end of volume </quote>

So, it is probably not safe to assume that an exit value of 1 always means 'success' for any version of tar, in the case of Formaline. How should we proceed with Formaline? The current state is not desirable. As far as I can see we have two options:

1) Assume that an exit value of 1 to be a 'success'. I do have a patch for this. 2) Test for gnu tar and only then assume 1)

Opinions?

Keyword:

Comments (6)

  1. Frank Löffler reporter
    • changed status to open
    • assigned issue to
    • removed comment

    I checked the source code of gnu tar: it does not abort in case of this error, it continues and creates the complete archive, but simply indicates this condition with a non-zero error code.

    I also implemented a check for gnu tar and will present it once I finished testing it.

  2. Ian Hinder
    • changed status to open
    • removed comment

    I have updated Formaline and I still get the problem. Erik pointed out that the $GTAR reference on line 13 of make.configuration.deps maybe should be $(GTAR). I made this change but I still get the problem.

  3. Erik Schnetter
    • removed comment

    The variable is called GNUTAR, and it should access $(TAR). There is no GTAR variable.

    I have just committed this correction.

  4. Erik Schnetter
    • changed status to resolved
    • removed comment

    The problem was that there was shell code using unquoted $ signs.

    This problem should be corrected in svn revision 198.

  5. Log in to comment