Hi, When extracting the download file (tar.gz) I get a trailing null block and a failure code from tar. In itself this would not be to bad. But I use these downloads in an automated process that fails if extracting tar archives fail. This actually is a problem with a lot of the Apache downloads. kind regards
What operating system, version of tar, and command-line are you using to trigger the error? If you've encountered this problem with a lot of Apache packages, then either: 1. the problem lies with the version of tar you're using and can be remedied by switching to a different version (e.g., GNU tar 1.15.1) 2. the problem lies with the Ant tar task, in which case you should refile this issue with the Apache Ant project. I've never encountered the problem, but--for other reasons--in my personal projects, I have taken to using: <exec executable="tar" dir="${top.dir}"> <arg line="zcf ${tarball.bin} ${project.name}"/> </exec> instead of the Ant tar and gzip tasks. However, jakarta-oro uses the Ant tar and gzip tasks, and it's entirely possiible the problem may lie there.
For what it's worth, I tried the following: if /bin/tar xf ~/jakarta-oro-2.0.8.tar; then echo SUCCESS; else echo FAILURE; fi with a now ancient BSD-derived version of tar on NEXTSTEP 3.3 m68k with the following identifying information in the binary: @(#)PROGRAM:tar PROJECT:sgcmds-56 DEVELOPER:root BUILT:Wed Oct 19 04:46:45 WET 1994 @(#) Copyright (c) 1980 Regents of the University of California. All rights reserved. and the result was SUCCESS. Historically, the NEXTSTEP version of tar tended to have many problems with tar files generated by other flavors tar. Therefore, if there's no issue with that tar, it's a good bet the problem isn't the archiving format. If you are uncompressing the archive first before untarring it (as opposed to using tar zxf as supported by GNU tar), tar may not be the problem at all. In some environments, creating a file from STDOUT like gunzip -c foo.tar.gz > foo.tar will add an additional null to mark EOF. If you're doing something like that, try not using STDOUT redirection. Alternatively, use the zip archive. Regardless, I don't believe this is really a jakarta-oro issue and will eventually mark the issue as Resolved: INVALID unless it turns out the problem is Ant tar or gzip task issue and the issue is refiled.
Resolving as WORKSFORME because the issue is not reproducible and there is insufficient information to determine if the user's version of tar is causing the problem or the ant tar task. In either case, it's not really an oro issue.