[jira] [Commented] (COMPRESS-203) Long directory names can not be stored in a tar archive because of error when writing PAX headers
[
https://issues.apache.org/jira/browse/COMPRESS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13908358#comment-13908358
]
Stefan Bodewig commented on COMPRESS-203:
-
I've opened COMPRESS-265 for the new issue
Long directory names can not be stored in a tar archive because of error when
writing PAX headers
-
Key: COMPRESS-203
URL: https://issues.apache.org/jira/browse/COMPRESS-203
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.4.1
Environment: Ubuntu 12.04 Linux 64 bit, Windows 7 64-bit
Reporter: Boris Terzic
Fix For: 1.5
Trying to add a directory to the TAR Archive that has a name longer than 100
bytes generates an exception with a stack trace similar to the following:
{noformat}
java.io.IOException: request to write '114' bytes exceeds size in header of
'0' bytes for entry
'./PaxHeaders.X/layers/openstreetmap__osm.disy.net/.tiles/1.0.0/openstreetmap__osm.disy.net/default/'
at
org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.write(TarArchiveOutputStream.java:385)
at java.io.OutputStream.write(Unknown Source)
at
org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.writePaxHeaders(TarArchiveOutputStream.java:485)
at
org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.putArchiveEntry(TarArchiveOutputStream.java:312)
at net.disy.lib.io.tar.TarUtilities.addFile(TarUtilities.java:116)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:158)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at net.disy.lib.io.tar.TarUtilities.tar(TarUtilities.java:77)
at net.disy.lib.io.tar.TarUtilities.tar(TarUtilities.java:42)
at
net.disy.gisterm.tilecacheset.export.TileCacheSetExporter.tarTreeStructure(TileCacheSetExporter.java:262)
at
net.disy.gisterm.tilecacheset.export.TileCacheSetExporter.export(TileCacheSetExporter.java:111)
at
net.disy.gisterm.tilecacheset.desktop.controller.ExportController$1.run(ExportController.java:81)
... 2 more
{noformat}
Informal source code investigation points to the problem being that for
directory entries the code assumes that the length is 0 in putArchiveEntry
(see TarArchiveOutputStream:321 ) but when writing the data, it actually
writes some data (the filename) and the length written (filename size) is
larger than the length expected (0).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COMPRESS-203) Long directory names can not be stored in a tar archive because of error when writing PAX headers
[
https://issues.apache.org/jira/browse/COMPRESS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13904196#comment-13904196
]
Stefan Bodewig commented on COMPRESS-203:
-
Patrik, could you please open a new ticket for this as it is certainly related
but still a different problem? And we'd also get better tracking of which
version is affected by which of the two bugs.
BTW, I agree that fixing {{stripTo7Bits}} is the better place to avoid the
problem.
Long directory names can not be stored in a tar archive because of error when
writing PAX headers
-
Key: COMPRESS-203
URL: https://issues.apache.org/jira/browse/COMPRESS-203
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.4.1
Environment: Ubuntu 12.04 Linux 64 bit, Windows 7 64-bit
Reporter: Boris Terzic
Fix For: 1.5
Trying to add a directory to the TAR Archive that has a name longer than 100
bytes generates an exception with a stack trace similar to the following:
{noformat}
java.io.IOException: request to write '114' bytes exceeds size in header of
'0' bytes for entry
'./PaxHeaders.X/layers/openstreetmap__osm.disy.net/.tiles/1.0.0/openstreetmap__osm.disy.net/default/'
at
org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.write(TarArchiveOutputStream.java:385)
at java.io.OutputStream.write(Unknown Source)
at
org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.writePaxHeaders(TarArchiveOutputStream.java:485)
at
org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.putArchiveEntry(TarArchiveOutputStream.java:312)
at net.disy.lib.io.tar.TarUtilities.addFile(TarUtilities.java:116)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:158)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at net.disy.lib.io.tar.TarUtilities.tar(TarUtilities.java:77)
at net.disy.lib.io.tar.TarUtilities.tar(TarUtilities.java:42)
at
net.disy.gisterm.tilecacheset.export.TileCacheSetExporter.tarTreeStructure(TileCacheSetExporter.java:262)
at
net.disy.gisterm.tilecacheset.export.TileCacheSetExporter.export(TileCacheSetExporter.java:111)
at
net.disy.gisterm.tilecacheset.desktop.controller.ExportController$1.run(ExportController.java:81)
... 2 more
{noformat}
Informal source code investigation points to the problem being that for
directory entries the code assumes that the length is 0 in putArchiveEntry
(see TarArchiveOutputStream:321 ) but when writing the data, it actually
writes some data (the filename) and the length written (filename size) is
larger than the length expected (0).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (COMPRESS-203) Long directory names can not be stored in a tar archive because of error when writing PAX headers
[
https://issues.apache.org/jira/browse/COMPRESS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13899352#comment-13899352
]
Patrik Burkhalter commented on COMPRESS-203:
We are running in troubles with an example like this:
{{0123456789/012345678901234567890123456789012345678901234567890123456789012345678901}}*Ü*{{345678901234567890123456789.txt}}
Please notice the character *'Ü'* in the file name.
{{stripTo7Bits(entryName)}} transforms the name to this string:
{{./PaxHeaders.X/0123456789/012345678901234567890123456789012345678901234567890123456789012345678901\345678901234567890123456789.txt}}
Then it gets truncated to:
{{./PaxHeaders.X/0123456789/012345678901234567890123456789012345678901234567890123456789012345678901}}\
After that, the constructor of TarArchiveEntry does a normalization on the file
name to change windows file separators to slashes:
{{./PaxHeaders.X/0123456789/012345678901234567890123456789012345678901234567890123456789012345678901/}}
At the end {{isDir}} is true:
{{boolean isDir = name.endsWith(/);}}
Our suggestion would be to change this:
{code:title=TarArchiveOutputStream.java|borderStyle=solid}
while (name.endsWith(/)) {
// TarEntry's constructor would think this is a directory
// and not allow any data to be written
name = name.substring(0, name.length() - 1);
}
{code}
To something like this:
{code:title=TarArchiveOutputStream.java|borderStyle=solid}
while (name.endsWith(/) || name.endsWith(\\)) {
// TarEntry's constructor would think this is a directory
// and not allow any data to be written
name = name.substring(0, name.length() - 1);
}
{code}
We think that the problem also could be avoided by modifying the method
{{stripTo7Bits}}.
Long directory names can not be stored in a tar archive because of error when
writing PAX headers
-
Key: COMPRESS-203
URL: https://issues.apache.org/jira/browse/COMPRESS-203
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.4.1
Environment: Ubuntu 12.04 Linux 64 bit, Windows 7 64-bit
Reporter: Boris Terzic
Fix For: 1.5
Trying to add a directory to the TAR Archive that has a name longer than 100
bytes generates an exception with a stack trace similar to the following:
{noformat}
java.io.IOException: request to write '114' bytes exceeds size in header of
'0' bytes for entry
'./PaxHeaders.X/layers/openstreetmap__osm.disy.net/.tiles/1.0.0/openstreetmap__osm.disy.net/default/'
at
org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.write(TarArchiveOutputStream.java:385)
at java.io.OutputStream.write(Unknown Source)
at
org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.writePaxHeaders(TarArchiveOutputStream.java:485)
at
org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.putArchiveEntry(TarArchiveOutputStream.java:312)
at net.disy.lib.io.tar.TarUtilities.addFile(TarUtilities.java:116)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:158)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at net.disy.lib.io.tar.TarUtilities.tar(TarUtilities.java:77)
at net.disy.lib.io.tar.TarUtilities.tar(TarUtilities.java:42)
at
net.disy.gisterm.tilecacheset.export.TileCacheSetExporter.tarTreeStructure(TileCacheSetExporter.java:262)
at
net.disy.gisterm.tilecacheset.export.TileCacheSetExporter.export(TileCacheSetExporter.java:111)
at
net.disy.gisterm.tilecacheset.desktop.controller.ExportController$1.run(ExportController.java:81)
... 2 more
{noformat}
Informal source code investigation points to the problem being that for
directory entries the code assumes that the length is 0 in putArchiveEntry
(see TarArchiveOutputStream:321 ) but when writing the data, it actually
writes some data (the filename) and the length written
[jira] [Commented] (COMPRESS-203) Long directory names can not be stored in a tar archive because of error when writing PAX headers
[
https://issues.apache.org/jira/browse/COMPRESS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540168#comment-13540168
]
Stefan Bodewig commented on COMPRESS-203:
-
The problem is not with directories with long names per se, it happens when the
name of the PAX header entry ends with a slash - which could happen for short
non-ASCII directory names or long file names if the name is truncated in the
wrong place. I'm working on a fix.
Long directory names can not be stored in a tar archive because of error when
writing PAX headers
-
Key: COMPRESS-203
URL: https://issues.apache.org/jira/browse/COMPRESS-203
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.4.1
Environment: Ubuntu 12.04 Linux 64 bit, Windows 7 64-bit
Reporter: Boris Terzic
Trying to add a directory to the TAR Archive that has a name longer than 100
bytes generates an exception with a stack trace similar to the following:
{noformat}
java.io.IOException: request to write '114' bytes exceeds size in header of
'0' bytes for entry
'./PaxHeaders.X/layers/openstreetmap__osm.disy.net/.tiles/1.0.0/openstreetmap__osm.disy.net/default/'
at
org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.write(TarArchiveOutputStream.java:385)
at java.io.OutputStream.write(Unknown Source)
at
org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.writePaxHeaders(TarArchiveOutputStream.java:485)
at
org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.putArchiveEntry(TarArchiveOutputStream.java:312)
at net.disy.lib.io.tar.TarUtilities.addFile(TarUtilities.java:116)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:158)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at
net.disy.lib.io.tar.TarUtilities.addDirectory(TarUtilities.java:162)
at net.disy.lib.io.tar.TarUtilities.tar(TarUtilities.java:77)
at net.disy.lib.io.tar.TarUtilities.tar(TarUtilities.java:42)
at
net.disy.gisterm.tilecacheset.export.TileCacheSetExporter.tarTreeStructure(TileCacheSetExporter.java:262)
at
net.disy.gisterm.tilecacheset.export.TileCacheSetExporter.export(TileCacheSetExporter.java:111)
at
net.disy.gisterm.tilecacheset.desktop.controller.ExportController$1.run(ExportController.java:81)
... 2 more
{noformat}
Informal source code investigation points to the problem being that for
directory entries the code assumes that the length is 0 in putArchiveEntry
(see TarArchiveOutputStream:321 ) but when writing the data, it actually
writes some data (the filename) and the length written (filename size) is
larger than the length expected (0).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
