[
https://issues.apache.org/jira/browse/TIKA-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18054485#comment-18054485
]
Iachimoe commented on TIKA-4630:
--------------------------------
I have just opened a new PR, #2553
My previous comment was inaccurate. I believed that INTERNAL_PATH was not being
added for the metadata of the tar file within the tgz, but this was mistaken.
The reason that I believed that is that the tests I was doing against my own
codebase (that uses tika) involved a TGZ file that did NOT have the file name
metadata in the gzip. It turns out that this is extremely common, because the
tar -czf command does not put this metadata in the tgz file (unlike the gzip
command).
Also other formats (I'm particularly interested in bz2) should have an
INTERNAL_PATH . I believe the most logical thing to do is to set the
INTERNAL_PATH to be the same as the RESOURCE_NAME . This would mean, for
example, that archive.tar.bz2 would have an INTERNAL_PATH of archive.tar. And
likewise for a tar.gz without the name embedded in the metadata.
The other aspect to my change is that I believe it's most correct that the
RESOURCE_NAME comes from the gzip metadata if available, rather than the
filename. My only concern with this is that it's (albeit minor) change in
existing behaviour, so not sure if it can go in a minor release?
In order to test this behaviour I made a new version of the test archive but
without the name in the gzip metadata. I didn't test other formats such as bz2,
but I believe that they should work as expected.
> embeddedRelationshipId is missing from tar files that are children of gzip
> files (i.e. tarballs)
> ------------------------------------------------------------------------------------------------
>
> Key: TIKA-4630
> URL: https://issues.apache.org/jira/browse/TIKA-4630
> Project: Tika
> Issue Type: Improvement
> Components: core
> Affects Versions: 3.2.3
> Reporter: Iachimoe
> Assignee: Tim Allison
> Priority: Major
> Attachments: tika-embedded-reln-jira.PATCH
>
>
> For some context, my usecase requires me to be able to precisely locate
> individual files within nested archives, using only metadata from tika.
> I have made this work for zip files using a combination of
> EMBEDDED_RELATIONSHIP_ID and EMBEDDED_RESOURCE_PATH. EMBEDDED_RESOURCE_PATH
> on its own does not work because it omits information about which directory a
> file is stored in within an archive. When trying to make it work for tgz
> files, the approach breaks because, while the parser quite reasonably
> considers "archive.tar" to be a child of "archive.tar.gz", the corresponding
> entry metadata lacks an EMBEDDED_RELATIONSHIP_ID. This makes it difficult to
> construct a path of the form
> "archive.tar.gz/archive.tar/my_folder/my_file.txt".
> I attach a rough solution (patch is against branch_3x), with unit test, that
> appears to work for my use case. The approach is for the
> RecursiveParserWrapper to set EMBEDDED_RELATIONSHIP_ID once parsing has
> completed if it has not been set during the parsing process. It sets it to
> the value of RESOURCE_NAME_KEY , which is probably not ideal, but in practice
> it seems to contain the filename and parent folders within the archive.
> Although the aim was to make this work for tar files, the unit test
> demonstrates that it has a similar effect for chidren of ODT files (this was
> an accident as the test archive that was already in the codebase happened to
> have ODT files).
> I could not find descriptions of exactly what EMBEDDED_RELATIONSHIP_ID and
> EMBEDDED_RESOURCE_PATH are meant to represent, so I'm not sure whether this
> approach is heading in the right direction, though it seems to work for my
> usecase. A future enhancement could be for the recursive parser to include a
> new field with the complete path to each file (again, imagining nested
> archives it might look something like
> "archive.tar.gz/archive.tar/folder1/nested.zip/folder2/file.txt").
> Looking forward to everybody's thoughts, and happy to make refinements to the
> proof of concept attached as needed.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
