Skip to content
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

Progress issue on multipart RAR archives #100

Open
DoctorW00 opened this issue Jan 16, 2024 · 6 comments
Open

Progress issue on multipart RAR archives #100

DoctorW00 opened this issue Jan 16, 2024 · 6 comments

Comments

@DoctorW00
Copy link

Hey, great project!

Got some issues on multipart RAR archives. The progress (in my case) only shows 1/5 of total (got 5 RAR archives).

I've used your example code from https://github.com/antony-jr/QArchive/tree/master/examples/disk_extractor - extraction always works single and multipart RAR archives. For testing i uses a ~500mb file packed in 5 RAR archives about 100mb each file. In this scenario, the progress counter ends at 20% but 100% was extracted.

Guess the problem could be around

qint64 size = archive_entry_size(entry);

If i use libarchive directly i use a loop to get all the total size of the RAR archive(s).

qint64 totalSize = 0;

while (archive_read_next_header(a, &entry) == ARCHIVE_OK)
{
	totalSize += archive_entry_size(entry);
}

qDebug() << "totalSize: " << totalSize;
@antony-jr
Copy link
Owner

Thanks for reporting this. We currently only read the size of the given input file as the total size. I guess we need to do something like your implementation. Will get back to it.

@antony-jr
Copy link
Owner

The problem with this is that we need to walk the entire archive just for the total size which is waste of time, don't you think?

@DoctorW00
Copy link
Author

DoctorW00 commented Jan 18, 2024

Thanks for your reply!

The code above is from the libarchive example and did work in my test project. Just for fun i also did try a ~86 GB multipart RAR archive split in 100 MB parts. It did start extraction right away, no major compute time for this so it can't be as bad. I guess reading the file header is quick, even on a 4 core pc and files stored a "slow" hdd. Also tested 7zip and unrar (had to get an older compiler for it) itself on this, also no issues regarding wasting time to read headers. Not sure and id did not check the code on this but usually the header is a limited space around the start of a file and there is no need to read in the whole file itself only the limited data a header can contain, that would explain the fast extraction of header information.

@DoctorW00
Copy link
Author

Small update on my side. Guess i'll stay with libarchive for now. Since the archive_read_open_filenames accepts a list of (RAR) files and works perfectly so far. Only downside is: lazy me has to code a lot more :( On the upside, i only need extraction for ZIP and RAR archives :)

Did check your code in qarchiveextractor_p.cc and it looks like you do not use the libarchive functions archive_read_open_filename or archive_read_open_filenames alt all, instead working with QFile and QFileInfo. I was up to implement it myself but that complicates it.

@antony-jr
Copy link
Owner

@DoctorW00 Sorry for the late reply, I was caught up at work.

Small update on my side. Guess i'll stay with libarchive for now. Since the archive_read_open_filenames accepts a list of (RAR) files and works perfectly so far. Only downside is: lazy me has to code a lot more :( On the upside, i only need extraction for ZIP and RAR archives :)

Did check your code in qarchiveextractor_p.cc and it looks like you do not use the libarchive functions archive_read_open_filename or archive_read_open_filenames alt all, instead working with QFile and QFileInfo. I was up to implement it myself but that complicates it.

Yes, there is reason for it, it is to support opening all types of QIODevice not just filenames, also this is safer. Yeah, let me work on it, its not that hard to implement.

@DoctorW00
Copy link
Author

Thanks, looking forward for an update supporting multi part archives.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants