DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=35842>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35842 ------- Additional Comments From [EMAIL PROTECTED] 2005-07-24 23:35 ------- 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. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
