|
|
WinRAR 7 Screenshot.png (6,826 bytes) |
|
|
Somebody correct me if I'm wrong, but the format is still named RAR 5. It's covered in the document titled "RAR 5.0 archive format" (https://www.rarlab.com/technote.htm -- search for "RAR 7.0"). It might be good if 'file' printed something like "RAR archive data, v5, RAR v7 to extract" for such files. Though I don't think that would be simple to do, in part because of RAR5's variable-length integers. |
|
|
The RAR application version is often conflated with the RAR format version. In this case: * WinRAR 5 is format 5 version 0. * WinRAR 6 is format 5 version 0. * WinRAR 7 is format 5 version 1 (and possibly format 5 version 0 with a large dictionary). The enduser won't understand this implementation detail and will reasonably expect to see "v7" in the `file` result. Per the rarlab.com technical note, doing two bitwise tests in the existing service header are likely enough to recognize the latest archive revision: 1. Check the format and version: IF { compression_information & 0x003f > 0 } THEN RETURN v7 2. Check for a large dictionary: ELSE IF { compression_information & 0x7c00 > 15 } THEN RETURN v7 |
|
|
BTW, you are right that the `vint` type makes adding this check non-trivial. Dunno how the RAR subblock test in Magdir/archive might be modified to make it happen. |
|
|
It should be pretty simple. file already has support for "varint"... |
|
|
There's some "varint" stuff in the source code, but it doesn't seem to be in working order. The farthest I can get is the error "invalid type 51 in mconvert". Note that RAR5 uses varints for things like segment sizes. To even get started parsing it properly, we'd have to be able to use varints in indirect offsets. (I'm *not* saying that would be *sufficient*! Maybe RAR5 would be hopeless anyway. I don't know.) |
- Anonymous
