RARV5 Support about pyeasyarchive HOT 6 CLOSED

Please attach a sample archive.

from pyeasyarchive.

Please add the constant and test. I'd appreciate you adding a unit-test, too, but, if not, I'll add one if you can attach a sample archive and/or detail how to produce a V5 archive.

https://github.com/libarchive/libarchive/blob/master/libarchive/archive.h#L343

from pyeasyarchive.

I'm afraid I'm away from my main computer right now, so the best I can do is attach a few samples for your reference.

I'll try to do more once I'm back.

GitHub doesn't support RAR attachments, so here's two links:
1
2

from pyeasyarchive.

The issue is your library. If you want to support a newer format than you need to have a newer version of libarchive.

Supported was added in libarchive/libarchive@7b3068c and it was included in https://github.com/libarchive/libarchive/releases/tag/v3.4.0 . Since I don't have an appropriate version of the library (3.1.2) nor have I been provided a procedure for making the archives nor has there been any previous request for this, I'm just closing this for now. Let me know if/when you upgrade your library and want to move forward.

from pyeasyarchive.

Duh, thanks. v3.4.0 is the version distributed in libarchive-dev as of Ubuntu 19.10.

It looks like the only way to actually create a RAR5 file is through WinRAR, as the format is somewhat proprietary, hence only read support existing in libarchive.

How do you handle the version requirement in this library? I have no problem adding the constant and unit test, I just want to make sure I understand how to make it fail properly on earlier versions (<3.4.0).

from pyeasyarchive.

It will already fail when it doesn't recognize the format value.

The purpose of the library is simply to bridge to a third-party library and marshal the arguments and results. We can streamline some complex patterns as necessary but I don't want to impose any extra interpretations or soft restrictions when the library is already going to fail if it needs to. We can always funnel well-defined error messages into specific exceptions if that looks to be helpful for common error conditions that might be handled a certain way by the caller, but I don't interpret this as being such a case.

from pyeasyarchive.