PS3 unRAR library (psl1ght) *working*

because he changed the name of dll.hpp to unrar.h when u install the lib to the environement (look in makefile). I didn't install the lib, it's included in mgz project, i just added the file include/unrar.h with inside #include "dll.hpp"
 
Zar said:
@bucanero eno
it's working here too. Although, I had to add in filefn.cpp : #include "os.hpp". It wasn't able to link "access" function from unistd.h in the elf when I was compiling mgz.

PS: it supports RAR5 too :p
Click to expand...

@Zar , I wasn't sure if MGZ used psl1ght or not, glad to know you got it working! :encouragement:
oh, weird that you had to include "os.hpp" :confused: but I bet we don't have the exact same setup/environment so anything is possible :-p

about access(), yes I forgot to mention: if you're using an old version of PSL1GHT, you won't have the access() function, but since it's basically used to check if a file exists, you can fix it defining your own "emulated" access():

Code: 
#include <fcntl.h>
#include <sys/stat.h>
#include <unistd.h>
int access(const char *fn, int flags)
{
  struct stat s;
  if (stat(fn, &s))
    return -1;
  if (s.st_mode & S_IFDIR)
    return 0;
  if (flags & W_OK)
  {
    if (s.st_mode & S_IWRITE)
      return 0;
    return -1;
  }
  return 0;
}

ps: since it's based on the official unrar code, it should support everything (all RAR format versions, volumes, encryption, passwords, solid archives, etc.) :D

docs about the available methods exported by the library:
http://goahomepage.free.fr/article/2000_09_17_unrar_dll/UnRARDLL.html
https://python-unrar.readthedocs.io/en/v0.3/_downloads/unrar_manual.txt
 
aldostools said:
I downloaded your unrar-master repo. I was able to build libunrar.a, but compiling the example doesn't find unrar.h
Click to expand...

sorry, as Zar said, "unrar.h" is created in portlibs/include when you "make install" the library. The original file is "dll.hpp" but honestly it made no sense to have such generic filename in the portlibs folder, so I decided to go with unrar.h . :)

also, keep an eye in the access() function, if you don't have a recent build of PSL1GHT that call will be missing when linking the final binary. You can fix it by adding your own access() function. See my previous post with the code for the emulated access with stat().

let me know if it worked, I'll try to update the example with another 2 cases, 1 for "list .RAR contents" and another for "test .RAR contents"

also, I'll probably rename the github repo to libunrar-ps3 , and add a proper README.md with instructions to build/install the library.
 
Md Hesam said:
anyone interest for 7z compressed file?
7z is also important like unrar,zip?
is there anyway extract 7z file using ps3?
Click to expand...

last time I checked the 7zip source code, it relies on specific threading functions to work. The linux port p7zip actually requires the pthread library, which is not available on the PS3. There's no "non-threaded" version, so either you build your own pthread library, or replace all the thread code using the PS3 threading methods.
With unRAR I was lucky that there's a non-threaded compile option, or else we wouldn't have unrar-ps3 right now.

For reference: Kakaroto ported a pthread-embedded library to PSL1GHT like 10 years ago. I was able to compile it with the latest source code, but the library is not working properly (fails to create threads/ work at all). :(
If anyone is eager to fix and update the pthread library, here's the source code: https://github.com/kakaroto/pthread-embeded
 
bucanero said:
sorry, as Zar said, "unrar.h" is created in portlibs/include when you "make install" the library. The original file is "dll.hpp" but honestly it made no sense to have such generic filename in the portlibs folder, so I decided to go with unrar.h . :)

also, keep an eye in the access() function, if you don't have a recent build of PSL1GHT that call will be missing when linking the final binary. You can fix it by adding your own access() function. See my previous post with the code for the emulated access with stat().

let me know if it worked, I'll try to update the example with another 2 cases, 1 for "list .RAR contents" and another for "test .RAR contents"

also, I'll probably rename the github repo to libunrar-ps3 , and add a proper README.md with instructions to build/install the library.
Click to expand...

Thank you Buc & @Zar !! I solved the compilation issues with the tip about dll.hpp

The issue with access() was solved commenting the lines: #define ENABLE_ACCESS in include\os.hpp
 
aldostools said:
@bucanero I implemented your zip, 7z & rar libraries in the PKGLAUNCH.
https://github.com/aldostools/webMAN-MOD/tree/master/_Projects_/wm_url_launcher

7zip and zip worked without issues. However I could not get the unrar library working with PKGLAUNCH,
but your example in github worked fine when I called it from PKGLAUNCH.

Do you have any idea about what could be happening?
Click to expand...

mmm... from what I saw, the only place you're calling unrar_extract(...) is here, right?:
https://github.com/aldostools/webMA...d5c50b/_Projects_/wm_url_launcher/main.c#L221

you say that if you call this line from PKGLAUNCH it works:
Code: 
unrar_extract("/dev_hdd0/tmp/archive.rar", "/dev_hdd0/tmp/");

if the code from my example worked, could you try this?
Code: 
unrar_extract(path, "/dev_hdd0/tmp");
and
Code: 
unrar_extract("/dev_hdd0/tmp/archive.rar", dest_path);

if that first change works, then it's something about the dest_path , but if it still fails and change #2 works, then I guess it's something related to the source path?

btw, my example is using a source file from /dev_hdd0 , PKGLAUNCH is opening the file from hdd0 or maybe somewhere else like dev_bdvd ?

note: I've fixed a .zip creation bug in Apollo, if the folder had more folders inside, they where not added. You can get the updated code here:
https://github.com/bucanero/apollo-ps3/blob/master/source/zip_util.c
 
Last edited:
bucanero said:
mmm... from what I saw, the only place you're calling unrar_extract(...) is here, right?:
https://github.com/aldostools/webMA...d5c50b/_Projects_/wm_url_launcher/main.c#L221

you say that if you call this line from PKGLAUNCH it works:
Code: 
unrar_extract("/dev_hdd0/tmp/archive.rar", "/dev_hdd0/tmp/");

if the code from my example worked, could you try this?
Code: 
unrar_extract(path, "/dev_hdd0/tmp");
and
Code: 
unrar_extract("/dev_hdd0/tmp/archive.rar", dest_path);

if that first change works, then it's something about the dest_path , but if it still fails and change #2 works, then I guess it's something related to the source path?

btw, my example is using a source file from /dev_hdd0 , PKGLAUNCH is opening the file from hdd0 or maybe somewhere else like dev_bdvd ?

note: I've fixed a .zip creation bug in Apollo, if the folder had more folders inside, they where not added. You can get the updated code here:
https://github.com/bucanero/apollo-ps3/blob/master/source/zip_util.c
Click to expand...

I think the issue was related to the available memory stack. I fixed the issue calling the external SELF (a modified version of example), instead of including RAR library into the project. The call from PKGLAUNCH uses a stack of 1MB.

In regards to the function extract_zip() in your zip_util.c I noticed that you call mkdirs before on every file.

You can speed up the zip extraction, creating the directories only when you find an entry that ends with '/'
https://github.com/aldostools/webMAN-MOD/blob/master/_Projects_/wm_url_launcher/zip_util.h#L141

Also the mkdirs is checked after the extract path, not from the root (first character in the path).

Also your extract buffer is 4KB (0x1000), Increasing it to 1MB (0x100000) helps to speed up the zip extraction.
 
aldostools said:
I think the issue was related to the available memory stack. I fixed the issue calling the external SELF (a modified version of example), instead of including RAR library into the project. The call from PKGLAUNCH uses a stack of 1MB.
Click to expand...

good to hear that you found a way to solve the unrar issue. Still, weird that the example worked but the same call from the PkgLauncher didn't.
For reference, I did a quick test on my side: I added the unrar(...) method to my PKGi homebrew app, built everything and I was able to unpack the archive.rar from within PKGi. (no issues)

In regards to the function extract_zip() in your zip_util.c I noticed that you call mkdirs before on every file.

You can speed up the zip extraction, creating the directories only when you find an entry that ends with '/'
https://github.com/aldostools/webMAN-MOD/blob/master/_Projects_/wm_url_launcher/zip_util.h#L141

Also the mkdirs is checked after the extract path, not from the root (first character in the path).

Also your extract buffer is 4KB (0x1000), Increasing it to 1MB (0x100000) helps to speed up the zip extraction.
Click to expand...

yes, I'm doing the mkdir on every file, because after doing some research on random .zip files, I found out that not every Zip tool creates the directory entries, so you might fail to unpack a file because you never created the directory.

As an example, a FILE.ZIP built with a nice tool would have:
Code: 
README.TXT
ARCHIVE.BIN
SOMEDIR/
SOMEDIR/FILE.GIF
SOMEDIR/FILE.BIN
OTHER/
OTHER/IMAGE.PNG

but you can find a FILE.ZIP built like this too:
Code: 
README.TXT
ARCHIVE.BIN
SOMEDIR/FILE.GIF
SOMEDIR/FILE.BIN
OTHER/IMAGE.PNG

in this case the tool didn't save the directory entries at all... :( as I couldn't trust the tool that generated the .zip , I went with the overhead of calling mkdir on every file.

Checking after the extract path is a nice improvement for sure. Also a bigger buffer would help too. I totally missed it... I was just "getting it to work" and then I guess didn't look into the code again.
btw, talking about the buffer, I'm thinking that it could be better to do just one malloc(buffer_size) at the beginning, and then re-use the same buffer for all the files unzipping, instead of a malloc(...) and free(...) for each file we unpack. That would speed up a bit too, reducing malloc/free calls and hopefully less memory fragmentation.

thanks for the review :encouragement:
 
bucanero said:
...as I couldn't trust the tool that generated the .zip , I went with the overhead of calling mkdir on every file.
Click to expand...

I understand, although I think it's unfair to pay that overhead all the time just because some tools create bad zip files.

IMHO it's better to not support these bad zips. Or you could check first if there are directory entries, then choose the faster method to create the directories ;)

bucanero said:
btw, talking about the buffer, I'm thinking that it could be better to do just one malloc(buffer_size) at the beginning, and then re-use the same buffer for all the files unzipping, instead of a malloc(...) and free(...) for each file we unpack. That would speed up a bit too, reducing malloc/free calls and hopefully less memory fragmentation.
Click to expand...
Yes, I forgot to mention that optimization. I already did that too:
https://github.com/aldostools/webMAN-MOD/blob/master/_Projects_/wm_url_launcher/zip_util.h#L165
 
hope i am not being inconvenient but i cant open rar files in multiman and i cant seem to fine an app to do it on ps3, is there something i am missing?
 
bucanero said:
I was bored today and I modified the unrar source to compile on PS3 (psl1ght)
so now I have a nice libunrar.a lying around :)

the question is, could it be useful for something? maybe including it in a file manager, if supporting .RAR files has any advantage for users... any other ideas?

btw, if anyone wants I can upload the source and changes to GitHub

cheers
Click to expand...
I guess making a file manager with the feature to extract zip, rar and 7zip(maybe more) can be useful for some user's. Multiman idk if it can extract large files but it surely can't extract file with multiple folders(was extracting gow3.zip and was given a blank folder. If you feel bored and have time surely make a file manager
 
theyaskedforanuniquename said:
I guess making a file manager with the feature to extract zip, rar and 7zip(maybe more) can be useful for some user's. Multiman idk if it can extract large files but it surely can't extract file with multiple folders(was extracting gow3.zip and was given a blank folder. If you feel bored and have time surely make a file manager
Click to expand...

Honestly I don't remember, but I thnk I implemented that feature in IRISMAN :D
 
You must log in or register to reply here.

Similar threads

Back
Top