[jira] Resolved: (COMPRESS-59) ArchiveEntry could have toString methods for formatting header contents
[ https://issues.apache.org/jira/browse/COMPRESS-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved COMPRESS-59. -- Resolution: Fixed Added ArchiveUtils which has a toString(ArchiveEntry) method. > ArchiveEntry could have toString methods for formatting header contents > --- > > Key: COMPRESS-59 > URL: https://issues.apache.org/jira/browse/COMPRESS-59 > Project: Commons Compress > Issue Type: Improvement >Reporter: Sebb >Priority: Minor > > I think it would be useful if the ArchiveEntry interface had some methods for > formatting the entry information as a String. > This could then be used to create an Archive scanner to list archive > contents, for example. > There should probably be two methods: > toShortString() - shows name, type and size only. > toLongString() - shows all the details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAEMON-124) error in website documentation
error in website documentation -- Key: DAEMON-124 URL: https://issues.apache.org/jira/browse/DAEMON-124 Project: Commons Daemon Issue Type: Bug Reporter: Eric Evans Priority: Minor The documentation at http://commons.apache.org/daemon/jsvc.html has an error. Under the section "Using jsvc" -> "Directly", the "void load(String[] arguments)" method should actually be "void init(String[] arguments)" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMPRESS-68) Filename suffix mappings for compression formats
[
https://issues.apache.org/jira/browse/COMPRESS-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated COMPRESS-68:
--
Description:
There are many file name suffix conventions like .tgz for gzipped .tar files
and .svgz for gzipped .svg files. It would be useful if Commons Compress knew
about these conventions and provided tools to help client applications to use
these conventions.
For example in Apache Tika we currently have the following custom code to
deduce the original filename from a gzipped file:
{code}
if (name.endsWith(".tgz")) {
name = name.substring(0, name.length() - 4) + ".tar";
} else if (name.endsWith(".gz") || name.endsWith("-gz")) {
name = name.substring(0, name.length() - 3);
} else if (name.toLowerCase().endsWith(".svgz")) {
name = name.substring(0, name.length() - 1);
} else if (name.toLowerCase().endsWith(".wmz")) {
name = name.substring(0, name.length() - 1) + "f";
} else if (name.toLowerCase().endsWith(".emz")) {
name = name.substring(0, name.length() - 1) + "f";
}
{code}
It would be nice if we instead could do something like this:
{code}
name = GzipUtils.getGunzipFilename(name);
{code}
was:
There are many file name suffix conventions like .tgz for gzipped .tar files
and .svgz for gzipped .svg files. It would be useful if Commons Compress knew
about these conventions and provided tools to help client applications to use
these conventions.
For example in Apache Tika we currently have the following custom code to
deduce the original filename from a gzipped file:
{code}
if (name.endsWith(".tgz")) {
name = name.substring(0, name.length() - 4) + ".tar";
} else if (name.endsWith(".gz") || name.endsWith("-gz")) {
name = name.substring(0, name.length() - 3);
} else if (name.toLowerCase().endsWith(".svgz")) {
name = name.substring(0, name.length() - 1);
} else if (name.toLowerCase().endsWith(".wmz")) {
name = name.substring(0, name.length() - 1) + "f";
} else if (name.toLowerCase().endsWith(".emz")) {
name = name.substring(0, name.length() - 1) + "f";
}
{code}
It would be nice if we instead could do something like this:
{code}
name = GzipUtils.getGunzipFilename(name);
{code}
> Filename suffix mappings for compression formats
>
>
> Key: COMPRESS-68
> URL: https://issues.apache.org/jira/browse/COMPRESS-68
> Project: Commons Compress
> Issue Type: New Feature
>Reporter: Jukka Zitting
>Priority: Minor
>
> There are many file name suffix conventions like .tgz for gzipped .tar files
> and .svgz for gzipped .svg files. It would be useful if Commons Compress knew
> about these conventions and provided tools to help client applications to use
> these conventions.
> For example in Apache Tika we currently have the following custom code to
> deduce the original filename from a gzipped file:
> {code}
> if (name.endsWith(".tgz")) {
> name = name.substring(0, name.length() - 4) + ".tar";
> } else if (name.endsWith(".gz") || name.endsWith("-gz")) {
> name = name.substring(0, name.length() - 3);
> } else if (name.toLowerCase().endsWith(".svgz")) {
> name = name.substring(0, name.length() - 1);
> } else if (name.toLowerCase().endsWith(".wmz")) {
> name = name.substring(0, name.length() - 1) + "f";
> } else if (name.toLowerCase().endsWith(".emz")) {
> name = name.substring(0, name.length() - 1) + "f";
> }
> {code}
> It would be nice if we instead could do something like this:
> {code}
> name = GzipUtils.getGunzipFilename(name);
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COMPRESS-68) Filename suffix mappings for compression formats
Filename suffix mappings for compression formats
Key: COMPRESS-68
URL: https://issues.apache.org/jira/browse/COMPRESS-68
Project: Commons Compress
Issue Type: New Feature
Reporter: Jukka Zitting
Priority: Minor
There are many file name suffix conventions like .tgz for gzipped .tar files
and .svgz for gzipped .svg files. It would be useful if Commons Compress knew
about these conventions and provided tools to help client applications to use
these conventions.
For example in Apache Tika we currently have the following custom code to
deduce the original filename from a gzipped file:
{code}
if (name.endsWith(".tgz")) {
name = name.substring(0, name.length() - 4) + ".tar";
} else if (name.endsWith(".gz") || name.endsWith("-gz")) {
name = name.substring(0, name.length() - 3);
} else if (name.toLowerCase().endsWith(".svgz")) {
name = name.substring(0, name.length() - 1);
} else if (name.toLowerCase().endsWith(".wmz")) {
name = name.substring(0, name.length() - 1) + "f";
} else if (name.toLowerCase().endsWith(".emz")) {
name = name.substring(0, name.length() - 1) + "f";
}
{code}
It would be nice if we instead could do something like this:
{code}
name = GzipUtils.getGunzipFilename(name);
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMPRESS-17) TAR format unspecified
[ https://issues.apache.org/jira/browse/COMPRESS-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12695145#action_12695145 ] Sebb commented on COMPRESS-17: -- @Reporter: Could you perhaps provide one or two (small) sample tar files we could use as test data? Ideally ones which require most of the new Posix features (but not huge files!) > TAR format unspecified > -- > > Key: COMPRESS-17 > URL: https://issues.apache.org/jira/browse/COMPRESS-17 > Project: Commons Compress > Issue Type: Bug > Environment: I use win xp sp3, but this is probably irrelevant. >Reporter: Sam Smith > Fix For: 1.1 > > > The TarArchive*putStream and Tar*putStream (e.g. > TarInputStream/TarOutputStream) javadocs say nothing about which specific TAR > format(s) they support. > They merely use the phrase "UNIX tar archive" which is WAY too generic of a > statement. > Here are some discussions on the various TAR formats: > http://www.gnu.org/software/tar/manual/html_section/Formats.html > http://leaf.dragonflybsd.org/cgi/web-man?command=tar§ion=5 > I HIGHLY URGE YOU TO SUPPORT THE POSIX.1-2001 SPECIFICATION, SINCE IT SOLVES > SO MANY ISSUES (e.g. it supports unlimited path lengths and file sizes). > Corollary, once you decide which TAR formats to support, this needs to be > added to the javadocs. Make sure that the javadocs discuss all limitations > for whatever format(s) are supported (especially on pathlengths, file sizes, > character sets, etc). Also make sure and include a hyperlink to a webpage > that describes the format standards. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMPRESS-68) Filename suffix mappings for compression formats
[
https://issues.apache.org/jira/browse/COMPRESS-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated COMPRESS-68:
--
Attachment: GzipUtils.patch
Added a patch for such utility code in a new GzipUtils class.
> Filename suffix mappings for compression formats
>
>
> Key: COMPRESS-68
> URL: https://issues.apache.org/jira/browse/COMPRESS-68
> Project: Commons Compress
> Issue Type: New Feature
>Reporter: Jukka Zitting
>Priority: Minor
> Attachments: GzipUtils.patch
>
>
> There are many file name suffix conventions like .tgz for gzipped .tar files
> and .svgz for gzipped .svg files. It would be useful if Commons Compress knew
> about these conventions and provided tools to help client applications to use
> these conventions.
> For example in Apache Tika we currently have the following custom code to
> deduce the original filename from a gzipped file:
> {code}
> if (name.endsWith(".tgz")) {
> name = name.substring(0, name.length() - 4) + ".tar";
> } else if (name.endsWith(".gz") || name.endsWith("-gz")) {
> name = name.substring(0, name.length() - 3);
> } else if (name.toLowerCase().endsWith(".svgz")) {
> name = name.substring(0, name.length() - 1);
> } else if (name.toLowerCase().endsWith(".wmz")) {
> name = name.substring(0, name.length() - 1) + "f";
> } else if (name.toLowerCase().endsWith(".emz")) {
> name = name.substring(0, name.length() - 1) + "f";
> }
> {code}
> It would be nice if we instead could do something like this:
> {code}
> name = GzipUtils.getGunzipFilename(name);
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COMPRESS-65) TarArchiveInputStream.matches() only works for tar archives whose first file is "test1.xml"
[ https://issues.apache.org/jira/browse/COMPRESS-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved COMPRESS-65. -- Resolution: Fixed The match method now works for Posix and GNU. > TarArchiveInputStream.matches() only works for tar archives whose first file > is "test1.xml" > --- > > Key: COMPRESS-65 > URL: https://issues.apache.org/jira/browse/COMPRESS-65 > Project: Commons Compress > Issue Type: Bug >Reporter: Sebb > > The tar header format does not have a "magic" number at the start, so in > general it is impossible to tell if an input file is a tar file without > reading a lot more data. > The current match() implementation assumes the first 8 bytes contain > "test1.xml", which is obviously a hack for testing purposes. > If more bytes are read from the input, it might be possible to implement a > working match() method: > The file must be at least 512 bytes long. > The following offsets have contents that could be checked: > Offset len > 148 8 Checksum for header block > 156 1 Link indicator (file type) - '0'-'6' or null > Other possible checks are: > - numeric fields must be octal > - filename fields must end in trailing nulls (but can a filename contain a > null?) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMPRESS-63) String#getBytes() is platform dependent
[ https://issues.apache.org/jira/browse/COMPRESS-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12695169#action_12695169 ] Sebb commented on COMPRESS-63: -- Added ArchiveUtils.matchAsciiBuffer(String, byte[]) method which uses the "ASCII" charset to compare strings with bytes. Still more fixes to apply. > String#getBytes() is platform dependent > --- > > Key: COMPRESS-63 > URL: https://issues.apache.org/jira/browse/COMPRESS-63 > Project: Commons Compress > Issue Type: Bug >Reporter: Sebb > > Many methods use the getBytes() method on Strings, however getBytes() uses > the platform default encoding, which may not be suitable. > It's also a bit inefficient to keep encoding the same strings. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COMPRESS-68) Filename suffix mappings for compression formats
[
https://issues.apache.org/jira/browse/COMPRESS-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved COMPRESS-68.
--
Resolution: Fixed
Thanks for the patch, added in:
URL: http://svn.apache.org/viewvc?rev=761492&view=rev
Log:
COMPRESS-68 Filename suffix mappings for compression formats
> Filename suffix mappings for compression formats
>
>
> Key: COMPRESS-68
> URL: https://issues.apache.org/jira/browse/COMPRESS-68
> Project: Commons Compress
> Issue Type: New Feature
>Reporter: Jukka Zitting
>Priority: Minor
> Attachments: GzipUtils.patch
>
>
> There are many file name suffix conventions like .tgz for gzipped .tar files
> and .svgz for gzipped .svg files. It would be useful if Commons Compress knew
> about these conventions and provided tools to help client applications to use
> these conventions.
> For example in Apache Tika we currently have the following custom code to
> deduce the original filename from a gzipped file:
> {code}
> if (name.endsWith(".tgz")) {
> name = name.substring(0, name.length() - 4) + ".tar";
> } else if (name.endsWith(".gz") || name.endsWith("-gz")) {
> name = name.substring(0, name.length() - 3);
> } else if (name.toLowerCase().endsWith(".svgz")) {
> name = name.substring(0, name.length() - 1);
> } else if (name.toLowerCase().endsWith(".wmz")) {
> name = name.substring(0, name.length() - 1) + "f";
> } else if (name.toLowerCase().endsWith(".emz")) {
> name = name.substring(0, name.length() - 1) + "f";
> }
> {code}
> It would be nice if we instead could do something like this:
> {code}
> name = GzipUtils.getGunzipFilename(name);
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
