-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(In)compatibility with external PBO programs #9
Comments
Hello, thanks for reporting a bug. I think this is due to the internal library misreading the headers. I have forked this project https://github.com/Paton7/PBOSharp and modified it a bit. Furthermore, I can solve this by doing two things:
I will do the first things since I do not have much time. But it will be kinda of an ugly fix. |
Hello, sorry for the long time that I have taken to start solving your problem. I have released a pre-release that in my opinion will fix your problem. I do not have any Linux environment where I could test this easily, so I cannot test it. If you can provide me a PBO that you create on Linux, maybe I can reproduce it a bit. If the problem is not solved, I will deeptest by using a Linux, but it will take some time to create the environment. The release: https://github.com/SteezCram/PboViewer/releases/tag/v1.4.2c |
Thank you for the update! Yes, this fixes the folders not being detected correctly - here's a comparison of the original sample file opened with the old version... ... and the 1.4.2c pre-release: However, the other issue with the file contents being incorrect is still present. As an example, the contents of the file "version.hpp" should be: #define CAFE_VERSION 1.7.0 ...but instead ends up as: if (isNil "f_var_logiVehi My guess is that there is a bug with how the file offsets are being calculated (either during read or write), as I recognise that snippet of SQF code from another file in the PBO. To follow up on this suspicion, I packed the original contents of the sample PBO using your 1.4.2c pre-release. Opening the resulting file, I now get: Notice that in the second picture, the folders and files are sorted alphabetically? In the picture above (using your latest version), they're not. On the flipside, opening "version.hpp" in this new PBO, I finally get: #define CAFE_VERSION 1.7.0 ...which is correct! So using PboViewer 1.4.2c, I can now pack and open my own PBOs fine, but it seems I am still unable to open files packed with external tools (as per the the original issue). Oh, and as requested, I've attached the repacked PBO from above. The original sample PBO is still in the first post. Thank you for all the support so far! |
Ok, I have also the problem with the base PBO. So I only solve one of your problem. I will try to find why we have this problem. Can you tell me also what kind of software did you use to pack the original PBO? EDIT: When searching for this: |
Late reply, but since the sample PBO is a user-generated mission, I don't know for sure what tool was used. I do know that it was packed on a Windows machine, and I'd guess they used PBO Manager.
For what it's worth, I tried opening both PBOs (original sample + repacked one) with PBO Manager on a Windows 10 VM, and in both cases I could open On a related note, I noticed 2 more things from this picture:
|
Ok, I will try to investigate further. But I am running out of options now. I do not know anything about this |
Describe the bug
PboViewer fails to open some PBO files correctly, specifically ones packed through external programs. I believe this might be related to how the file paths are stored inside the file?
To Reproduce
Steps to reproduce the behavior:
Expected behavior
PboViewer should ideally be compatible with other PBO programs. Currently I am unable to extract PBOs from users on Windows computers (who generally use PBO Manager on their end) as I only have access to PboViewer, being on Linux myself.
Screenshots
Operating system
Arch Linux 6.11.7-arch1-1
Additional context
Sample PBO mentioned above
From a quick look, it seems as if the file lengths are correct, but the contents are completely mismatched (each file contains data from a completely different file). I'm also noticing that the file paths use backslashes, which is normal (and expected) for Windows but forbidden on Linux, so maybe part of the reason why it's breaking.
The text was updated successfully, but these errors were encountered: