Tycho creating tar files with extended header keyword 'LIBARCHIVE.creationtime'

[jonahgraham]

I recently updated to newer Tycho (2.7.1 -> 3.0.5) for creating EPP and now I get this warning for each file in the tar when I untar on Linux:

tar: Ignoring unknown extended header keyword 'LIBARCHIVE.creationtime'

Can the extended header keywords be removed as it generates warnings on multiple users machines even with recent gnu tar implementations. AFAIU this is a bsd tar extension.

xref: eclipse-platform/eclipse.platform.releng#147

[laeubi]

Tycho uses org.apache.commons.compress.archivers.tar.TarArchiveOutputStream so if you think anything is invalid there in general it might be best reported there, as far as I can see it only uses POSIX extensions here:

https://github.com/eclipse-tycho/tycho/blob/master/tycho-p2-director-plugin/src/main/java/org/eclipse/tycho/plugins/tar/TarGzArchiver.java

so I can't see any immediate actions Tycho can perform here.

[jonahgraham]

This is the change in Commons compress that added the header apache/commons-compress#254

[jonahgraham]

The issue report is here https://issues.apache.org/jira/projects/COMPRESS/issues/COMPRESS-612?filter=allissues

[jonahgraham]

I'm trying to decide whether to invest more time on this.

Is no one else seeing these warnings when decompressing? I don't want to spend time answering support requests on this issue now that EPP will be distributing this.

[laeubi]

Is no one else seeing these warnings when decompressing?

I usually not use the commandline to uncompress archives.

I'm trying to decide whether to invest more time on this.

This is fair enough, but I get the feeling that the most valuable way would be to report it to the tar tool that:

1. The same warning should not be reported more than once
2. extended header 'LIBARCHIVE.creationtime' should either be supported or silently ignored (so it is not reported as unknown)

From Tycho side I don't see anything we can do as it seems it is a valid archive and the behavior itself is not configurable with the library we use here.

[jonahgraham]

I'm going to refer back to this issue if anyone raises it, but I am not spending more time on this. If needed I will make an issue in EPP - the tar suggestion is interesting, but lead time on tar changes is so long it doesn't help me.

[HannesWell]

This is a reoccurring topic, see for example eclipse-platform/eclipse.platform.releng.aggregator#2529 and also the Eclipse SDK I-build test logs seem to consists by a major portion of the mentioned tar warnings.

Although this would ideally be fixed in the tar tool I think such fix would take quite some time until it is available on the build-machines and the computers of Tycho users respectively of the users of Eclipse products.

I looked a bit into this and I have the impression that it might be possible to unset the creation time of created tar-entries in

tycho/tycho-p2-director-plugin/src/main/java/org/eclipse/tycho/plugins/tar/TarGzArchiver.java

Lines 116 to 133 in 2e98ec9

	private TarArchiveEntry createTarEntry(File tarRootDir, File source) throws IOException {
	String pathInTar = slashify(tarRootDir.toPath().relativize(source.toPath()));
	log.debug("Adding entry " + pathInTar);
	TarArchiveEntry tarEntry;
	if (isSymbolicLink(source) && resolvesBelow(source, tarRootDir)) {
	// only create symlink entry if link target is inside archive
	tarEntry = new TarArchiveEntry(pathInTar, TarConstants.LF_SYMLINK);
	tarEntry.setLinkName(slashify(getRelativeSymLinkTarget(source, source.getParentFile())));
	} else {
	tarEntry = new TarArchiveEntry(source, pathInTar);
	}
	PosixFileAttributes attrs = getAttributes(source);
	if (attrs != null) {
	tarEntry.setMode(FilePermissionHelper.toOctalFileMode(attrs.permissions()));
	}
	tarEntry.setModTime(source.lastModified());
	return tarEntry;
	}

I'm currently trying it out locally and will create a PR if that works as desired.

[laeubi]

I'm currently trying it out locally and will create a PR if that works as desired.

I'm not sure confident there is something to "fix" because obviously there are users that benefit from such extension (otherwise I doubt one would have added it in a library).

And obviously people are not concerned enough to fix it at the root, I not think Tycho should add hacks to fix upstream bugs/features....

[HannesWell]

I'm currently trying it out locally and will create a PR if that works as desired.

I'm not sure confident there is something to "fix" because obviously there are users that benefit from such extension (otherwise I doubt one would have added it in a library).

It's clearly a workaround and not a fix. I cannot say anything about the usefulness I can only say that (GNU) tar currently emits a lot of warnings and that silences that warnings by not setting the corresponding attribute:

• Don't write LIBARCHIVE.creationtime attribute in tar.gz archive entries #4427

There is also a discussion on the GNU tar mailing list about this issue, originating from exactly this issue:

• https://lists.gnu.org/archive/html/bug-tar/2024-03/msg00014.html
• https://lists.gnu.org/archive/html/bug-gnulib/2024-03/msg00189.html

They say that tar could just ignore this option (don't know why this has not been implemented yet), but they also say that it's not a standard extension and not always useful or applicable.
And since, as far as I know, nobody complained before that this attribute was missing, but now that it's there it seems to cause trouble in numerous cases.

[collinfunk]

@HannesWell Thanks for updating that bugzilla page. I've suggested the GNU tar maintainers ignore this header [1]. Hopefully it will be accepted before it causes more bug reports. :)

[1] https://lists.gnu.org/archive/html/bug-tar/2024-11/msg00005.html

[HannesWell]

@HannesWell Thanks for updating that bugzilla page. I've suggested the GNU tar maintainers ignore this header [1]. Hopefully it will be accepted before it causes more bug reports. :)

[1] https://lists.gnu.org/archive/html/bug-tar/2024-11/msg00005.html

Thank you for that! I hope so, too.

In the meantime I have created #4427 to be able to workaround this issue for tar.gz archives built for Eclipse products.