Skip to content

Don't create tmp folders when downloading #707

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

Open
4 tasks done
kkurootetsuro opened this issue Feb 14, 2025 · 5 comments
Open
4 tasks done

Don't create tmp folders when downloading #707

kkurootetsuro opened this issue Feb 14, 2025 · 5 comments

Comments

@kkurootetsuro
Copy link

Describe your suggested feature

If the app crashes mid download, the tmp folder will stay there until the user notices (which can take a while)
Is it possible to make it not create the tmp folder?
Suwayomi as far as I can tell works like that. It doesn't create a tmp folder. When the download finishes, it simply adds the .cbz to the folder.

Other details

No response

Acknowledgements

  • I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
  • I have written a short but informative title.
  • I have updated the app to version 1.12.1.
  • I will fill out all of the requested information in this form.
@cuong-tran
Copy link
Collaborator

Would a re-download will overwrite tmp folder?

@JoeloJoestar
Copy link

@cuong-tran the re-download checks for already existing pics in tmp folder and resume from the missing ones going forward.

@kkurootetsuro The created folder while downloading is called "<chapter_name>_tmp". The tmp is there in fact to let user resume, what is your solution? Where will the pics get stored while downloading? And if you suggest to make this space very volatile, getting deleted on the stop, imagine redownloading 200+ pages of a chapter because internet went off before finishing last couple of pics.
Maybe you mean that the folder created while downloading will not be called "tmp" but the name of the chapter only already, then the app cannot recognize anymore between fully downloaded and not.

My solution is to forget about it, until when in need and in mood I load the folder up in the PC, search for "tmp" folders and clean up, since these pending up are so much smaller in number compared to those complete successfully.

@kkurootetsuro
Copy link
Author

@cuong-tran the re-download checks for already existing pics in tmp folder and resume from the missing ones going forward.

@kkurootetsuro The created folder while downloading is called "<chapter_name>_tmp". The tmp is there in fact to let user resume, what is your solution? Where will the pics get stored while downloading? And if you suggest to make this space very volatile, getting deleted on the stop, imagine redownloading 200+ pages of a chapter because internet went off before finishing last couple of pics. Maybe you mean that the folder created while downloading will not be called "tmp" but the name of the chapter only already, then the app cannot recognize anymore between fully downloaded and not.

My solution is to forget about it, until when in need and in mood I load the folder up in the PC, search for "tmp" folders and clean up, since these pending up are so much smaller in number compared to those complete successfully.

Dude, I'm not asking for this with no reason. Maybe there is a better solution but I'm not sure what it would be. Anyway, if the app crashes during any download, the tmp folder won't be helping anymore. It'll just be a headache. Every time the app crashes while I'm downloading something, I have to go the folder, delete the tmp file and start redownloading again because no matter what I do, it won't continue.

@cuong-tran
Copy link
Collaborator

then I should investigate why it can't resume downloading instead.

@kkurootetsuro
Copy link
Author

then I should investigate why it can't resume downloading instead.

also a good option

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

3 participants