You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Overview
If downloading fails because of insufficient disk space,
.part
file remains and is not removed.Steps to Reproduce
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.The text was updated successfully, but these errors were encountered: