[
https://issues.apache.org/jira/browse/TIKA-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18139096#comment-18139096
]
ASF GitHub Bot commented on TIKA-5043:
--------------------------------------
dschmidt commented on PR #3536:
URL: https://github.com/apache/tika/pull/3536#issuecomment-6665453481
Thanks, both addressed in 51dd1f9f1b (and main merged).
1. RAR5 times are now set as instants (`rar.getFormat() ==
RarFormat.RAR50`), RAR4 stays DOS local time. The synthetic RAR5 in the test
now carries an mtime, parsed under UTC, America/New_York and Asia/Tokyo:
`2023-11-14T22:13:20Z` in all three; before, it came out zoneless and moved
with the zone.
2. Archives are opened with `maxDictionarySize` 1 GB, what WinRAR 5 and 6
write. There is no test for it: junrar doesn't check the dictionary of stored
entries, which have no window, and building a compressed RAR5 needs WinRAR.
Happy to make the cap configurable if you prefer.
> RarParser refuses RAR5 archives although junrar 8 reads them
> ------------------------------------------------------------
>
> Key: TIKA-5043
> URL: https://issues.apache.org/jira/browse/TIKA-5043
> Project: Tika
> Issue Type: Bug
> Components: parser
> Reporter: Dominik Schmidt
> Priority: Major
>
> RarParser throws {{UnsupportedFormatException("Tika does not yet support rar
> version 5.")}} for any {{application/x-rar-compressed; version=5}} before
> junrar sees the file. junrar has read RAR5 (and RAR7) since 8.0.0 (junrar PR
> #289), and Tika depends on junrar 8.1.2.
> Checked with a real RAR5 archive (a 50-page comic book archive from
> archive.org): {{/rmeta}} answers with the exception and no entries, while
> junrar 8.1.2 called directly lists all 50 entries and extracts them. A RAR4
> archive works either way.
> Removing the version check should be enough; tests with a RAR5 fixture would
> show it. Related: TIKA-3211, whose premise (junrar has no RAR5) no longer
> holds.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
