You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 21, 2020. It is now read-only.
extractFile does not accept a FileHeader which was obtained while Archive was reading a different Volume. So if you collect the headers to build up a file tree and then later pass one of these header objects back to extractFile, this check rejects it:
if (!headers.contains(hd)) {
throw new RarException(RarExceptionType.headerNotInArchive);
}
Removing this check fixes the problem at the expense of losing the check. Keeping track of all headers ever handed out might be a better solution to this part of the issue.
Additionally, if Archive is currently pointing at a volume which is not the first volume in the set, you can get a CRC error, presumably because it doesn't start reading from the first file which contained the header.
The workaround I used to get around both of these related issues was to create a brand new instance of Archive and call extractFile on that. That way, I'm always on the first file.
The other major problem which will bite people without them realising it is that getFileHeaders() always returns only the headers for the current volume. If you want to find all files in the archive, you have to manually call the volume-related methods on Archive, which feels like a bit of a dodgy workaround (works, though.)
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
extractFile does not accept a FileHeader which was obtained while Archive was reading a different Volume. So if you collect the headers to build up a file tree and then later pass one of these header objects back to extractFile, this check rejects it:
Removing this check fixes the problem at the expense of losing the check. Keeping track of all headers ever handed out might be a better solution to this part of the issue.
Additionally, if Archive is currently pointing at a volume which is not the first volume in the set, you can get a CRC error, presumably because it doesn't start reading from the first file which contained the header.
The workaround I used to get around both of these related issues was to create a brand new instance of Archive and call extractFile on that. That way, I'm always on the first file.
The other major problem which will bite people without them realising it is that getFileHeaders() always returns only the headers for the current volume. If you want to find all files in the archive, you have to manually call the volume-related methods on Archive, which feels like a bit of a dodgy workaround (works, though.)
The text was updated successfully, but these errors were encountered: