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

.part file remains when encountered insufficient disk space #968

Open
iowk opened this issue Oct 17, 2024 · 1 comment
Open

.part file remains when encountered insufficient disk space #968

iowk opened this issue Oct 17, 2024 · 1 comment
Labels

Comments

@iowk
Copy link
Contributor

iowk commented Oct 17, 2024

Overview

If downloading fails because of insufficient disk space, .part file remains and is not removed.

Steps to Reproduce

  1. Sync iCloud Photos on a device with insufficient disk space.
  2. Downloading should fail on some files, logging IOError while writing...

Expected Behavior

The .part file should be deleted after downloading fails.

Actual Behavior

The .part file remains.

Context

I think we can add a try-finally block in download_response_to_path to remove the .part file on error.

@iowk iowk added the bug label Oct 17, 2024
@AndreyNikiforov
Copy link
Collaborator

Thanks for reporting. Yes, .part files will be left on the drive if app crashes. A number of thoughts on the subject:

  • there may be recoverable errors during downloading, e.g. re-auth - hypothetical, and it would be beneficial to resume downloading rather then deleting and restarting
  • there may be app crashes that cannot be caught in code (e.g. os-level terminations)
  • .part files can be stored in tmp location of the OS and in case of crashes, OS will take care of cleaning space
  • using tmp storage may add extra complexities (where tmp storage is managed separately from main one) and performance degradation (for final move of the file)
  • .part files in final destination may impact backups (.part files will be backed up) - undesirable

Seems that simple try-catch wrapping and silent file deletion may cover most probable case (space issues). It will not hurt re-auth hypothetical case.

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

No branches or pull requests

2 participants