starred/sharpcompress
1
0
Fork 0
mirror of https://github.com/adamhathcock/sharpcompress.git synced 2026-02-09 05:24:55 +00:00
Code Issues 975 Packages Projects Releases 20 Wiki Activity

Cannot get RAR version from the library API #490

New Issue
Open
opened 2026-01-29 22:12:52 +00:00 by claunia · 2 comments
claunia commented 2026-01-29 22:12:52 +00:00
Owner
Copy Link

Originally created by @ghost on GitHub (Jan 23, 2022).

Currently encrypted RAR 5.0 files cannot be read by sharpcompress. But currently sharpcompress currently supports the reading of encrypted files of 4.0.

If the file version number of RAR can be directly read in the program, then the end user can be directly prompted that the encrypted file of 5.0 is not supported. At present, since the version number cannot be obtained, the end user can never judge which files are in the process of using can be read normally.

If a Property API can be provided to display the version number of RAR or other formats, after RAR 6.0 or RAR 7.0 comes out in the future, programmers can use this Property to prompt users which files can be read normally.

supplement 1:

It is assumed that RAR 6.0, RAR 7.0 or later version is released later. There will be a time gap when sharpcompress is updated so that sharpcompress supports the latest RAR version number. During this period of time (maybe several months or more), through this Property, users can be prompted for files that do not currently support this RAR version number.

Without this property, all RAR files are obfuscated. The user has no way of knowing which files can be opened, or which files cannot be opened.

Of course, these steps can also be simplified, for example, there is a property FileVersionIsSupported (and property EncryptedFileVersionIsSupported for encrypted files), which can simply tell the user. This version number is currently fully supported, or is still in the development stage.

Both property FileVersionNumer and property FileVersionIsSupported will be of great help to the user.

Originally created by @ghost on GitHub (Jan 23, 2022). Currently encrypted RAR 5.0 files cannot be read by sharpcompress. But currently sharpcompress currently supports the reading of encrypted files of 4.0. If the file version number of RAR can be directly read in the program, then the end user can be directly prompted that the encrypted file of 5.0 is not supported. At present, since the version number cannot be obtained, the end user can never judge which files are in the process of using can be read normally. If a Property API can be provided to display the version number of RAR or other formats, after RAR 6.0 or RAR 7.0 comes out in the future, programmers can use this Property to prompt users which files can be read normally. supplement 1: It is assumed that RAR 6.0, RAR 7.0 or later version is released later. There will be a **time gap** when sharpcompress is updated so that sharpcompress supports the latest RAR version number. During this period of time (maybe several months or more), through this Property, users can be prompted for files that do not currently support this RAR version number. Without this property, all RAR files are obfuscated. The user has no way of knowing which files can be opened, or which files cannot be opened. Of course, these steps can also be simplified, for example, there is a property **FileVersionIsSupported** (and property **EncryptedFileVersionIsSupported** for encrypted files), which can simply tell the user. This version number is currently fully supported, or is still in the development stage. Both property **FileVersionNumer** and property **FileVersionIsSupported** will be of great help to the user.
claunia added the enhancementup for grabs labels 2026-01-29 22:12:52 +00:00
claunia commented 2026-01-29 22:12:52 +00:00
Author
Owner
Copy Link

@adamhathcock commented on GitHub (Jan 24, 2022):

Could be a good idea to add

@adamhathcock commented on GitHub (Jan 24, 2022): Could be a good idea to add
claunia commented 2026-01-29 22:12:52 +00:00
Author
Owner
Copy Link

@Nanook commented on GitHub (Jul 15, 2022):

After some investigation it appears there isn't a 100% way to determine which version of WinRar/Rar created an archive. I've implemented a solution which I will be submitting that does it based on the compression algorithm used on the files. Two properties have been added to the RarArchive class:

  • MinVersion
  • MaxVersion

Some examples:

  • If the algorithm is 20 then the archive was created by MinVersion=2 MaxVersion=2
  • If the algorithm is 29 then the archive was created by MinVersion=3 MaxVersion=4
  • If the algorithm is 50 then the archive was created by MinVersion=5 MaxVersion=6

Does this seem fair?

@Nanook commented on GitHub (Jul 15, 2022): After some investigation it appears there isn't a 100% way to determine which version of WinRar/Rar created an archive. I've implemented a solution which I will be submitting that does it based on the compression algorithm used on the files. Two properties have been added to the RarArchive class: - MinVersion - MaxVersion Some examples: - If the algorithm is 20 then the archive was created by MinVersion=2 MaxVersion=2 - If the algorithm is 29 then the archive was created by MinVersion=3 MaxVersion=4 - If the algorithm is 50 then the archive was created by MinVersion=5 MaxVersion=6 Does this seem fair?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
duplicate
enhancement
feedback requested
not bug
pull-request
Mirrored from GitHub Pull Request
 question
up for grabs
wontfix
No Label enhancement up for grabs
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/sharpcompress#490
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?