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

Fixed Issue #55 #56

Merged
merged 7 commits into from
Mar 6, 2023
Merged

Fixed Issue #55 #56

merged 7 commits into from
Mar 6, 2023

Conversation

Aurillium
Copy link
Contributor

@Aurillium Aurillium commented Mar 5, 2023

Pull Request

Types of changes

Fixed issue #55

Description

Summary

  1. Changed the default file size value from 0 to u64::MAX in order to prevent downloads without a content-length being skipped for no reason.
  2. On a successful download, the file size on disk is returned as opposed to the potentially inaccurate value that came from content-length

Original

image
image

Current

image
image

Fixed

Issue #55 (files that hadn't been downloaded were being skipped)

Testing

Essentially just the simple example with several different files; the change was very minor (basically a value was changed from 0 to u64::MAX, logically everything checks out, and in testing there were no issues)

Checklist

  • I have updated the documentation accordingly (only code comments needed changing)
  • I have updated the Changelog (if applicable) (N/A)

Issue #55

@Aurillium Aurillium mentioned this pull request Mar 5, 2023
Copy link
Owner

@rgreinho rgreinho left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for reporting the issue and providing a patch!

Your solution does not seem unreasonable, but it feels a bit weird using u64::MAX as a default value. What happens to the progress bar when size is u64::MAX in .to_progress_bar(size)?

What do you think of simply updating the condition to if size_on_disk > 0 && size == size_on_disk instead? That would prevent the skip.

Also, for the final report to contain the right size by reading on disk, the metadata would need to be refreshed.

Copy link
Owner

@rgreinho rgreinho left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks much cleaner like that! Good job 👍

Just one or two minor things to clean up and then we can merge it.

@@ -260,6 +271,9 @@ impl Downloader {
// Advance the main progress bar.
main.inc(1);

// Create a new summary with the real download size
println!("Size on disk {}", size_on_disk);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove the println!.

Comment on lines 219 to 224
// append: If we can't resume from where we left off,
// we should overrwite the file and start again
// This also prevents corrupting files by writing
// to them again
// write: We are writing to the file
// create: The file should be created if it doesn't exist
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Documentation is good to add in general, but in this case I don't think it is necessary to document each member of the builder. They are all well documented in the Tokio documentation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh right, sorry, I completely overlooked that println, and yeah that's fair
I'll fix both of those quick now

@Aurillium
Copy link
Contributor Author

Okay those should be fixed now

@rgreinho
Copy link
Owner

rgreinho commented Mar 6, 2023

@Aurillium I don't understand why the formatter is not happy, but if you reorder the builder's lines, then is works:

let mut file = match OpenOptions::new()
       .create(true)
       .write(true)
       .append(can_resume)
       .open(output)
       .await;

🤷

@Aurillium
Copy link
Contributor Author

Interesting haha, but should be all good now

@kodiakhq kodiakhq bot merged commit 5ac6bca into rgreinho:main Mar 6, 2023
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

Successfully merging this pull request may close these issues.

2 participants