<div class="gmail_quote">On Tue, Oct 26, 2010 at 4:31 PM, Frank Loeffler <span dir="ltr">&lt;<a href="mailto:knarf@cct.lsu.edu">knarf@cct.lsu.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<br>
I forward the following trac message to the users mailing list to start a<br>
discussion on this issue, but to have the issue recorded in trac at the<br>
same time.<br>
<br>
Frank<br>
<br>
----- Forwarded message from Einstein Toolkit &lt;<a href="mailto:trac-noreply@einsteintoolkit.org">trac-noreply@einsteintoolkit.org</a>&gt; -----<br>
<br>
#69: Formaline might stop build because of errors reported by tar<br>
--------------------+-------------------------------------------------------<br>
 Reporter:  knarf   |       Owner:<br>
     Type:  defect  |      Status:  new<br>
 Priority:  major   |   Milestone:  ET_2010_11<br>
Component:  Cactus  |     Version:<br>
 Keywords:          |<br>
--------------------+-------------------------------------------------------<br>
 Beginning with version 1.16 of gnu tar:<br>
 &lt;quote&gt;<br>
 After creating an archive, tar exits with code 1 if some files were<br>
 changed while being read.  Previous versions exited with code 2 (fatal<br>
 error), and only if some files were truncated while being archived.<br>
 &lt;/quote&gt;<br>
<br>
 Even reading a file (as is done when compiling it in parallel) will change<br>
 it in tar&#39;s view, because this changes the atime of the file. There does<br>
 not seem to be an option which turns this new behavior off. Instead it is<br>
 recommended to check the exit code of tar which is<br>
 0: if everything went ok<br>
 1: if files changed while being read/written<br>
 2: if some other error occurs.<br>
<br>
 This means that Formaline should treat an exit code of 1 in tar as &#39;ok&#39;,<br>
 while currently it aborts the build. However, this is safely true only for<br>
 gnu tar. For example the version of tar on the &#39;pelican&#39; system states:<br>
 &lt;quote&gt;<br>
 0 Successful completion.<br>
 &gt;0 An error occurred.<br>
 &lt;/quote&gt;<br>
 This is too vague to decide if ignoring an exit code of 1 can also here be<br>
 ignored. File changes are a kind of error - of a kind one might be able to<br>
 ignore. The documentation of this old version of tar doesn&#39;t mention which<br>
 values are actually used for which errors though.<br>
<br>
 Somewhere else I found [<a href="http://aplawrence.com/Bofcusm/2073.html" target="_blank">http://aplawrence.com/Bofcusm/2073.html</a> this]:<br>
 &lt;quote&gt;<br>
 0 - success<br>
 1 - bad directory tree, failed to extract a requested file,<br>
     input file same as output file, failed to open input file,<br>
     could not create link, link table malloc  failure<br>
 2 - internationalization error that should never occur,<br>
     checksum error<br>
 5 - checksum error<br>
 9 (EBADF) - error reading /etc/default/tar, misplaced end of volume<br>
 &lt;/quote&gt;<br>
<br>
 So, it is probably not safe to assume that an exit value of 1 always means<br>
 &#39;success&#39; for any version of tar, in the case of Formaline. How should we<br>
 proceed with Formaline? The current state is not desirable. As far as I<br>
 can see we have two options:<br>
<br>
 1) Assume that an exit value of 1 to be a &#39;success&#39;. I do have a patch for<br>
 this.<br>
 2) Test for gnu tar and only then assume 1)<br>
<br>
 Opinions?</blockquote><div><br></div><div>I would check whether it is gnu tar, then check its version, and then possibly accept an exit value of 1 as correct.</div><div><br></div><div>Alternatively, we could build the tar files only after the thorn has been built, and the source files won&#39;t be read any more. (This may already be the case.) We would also need to build the tar files either before or after git is run.</div>
<div><br></div><div>-erik</div></div><div><br></div>-- <br>Erik Schnetter &lt;<a href="mailto:schnetter@cct.lsu.edu">schnetter@cct.lsu.edu</a>&gt;   <a href="http://www.cct.lsu.edu/~eschnett/">http://www.cct.lsu.edu/~eschnett/</a><br>
<br>