image download cancel disrepancy - lose progress if zipfile, keep if not
If the user begins downloading some images, then partway through the process presses "cancel", whether or not the already downloaded images are retained depends on whether or not images are stored in zipfiles.
If images are stored in zipfiles, then progress is lost when cancelled.
If images are NOT stored in zipfiles, then the images downloaded so far are kept.
I am guessing this is because when images are stored in zipfiles, there is a temp file used for the download process - and pressing cancel simply deletes those temp files. I would like to propose that when cancel is pressed, the temp files are processed to keep the images that have been downloaded so far so that progress is not lost. (Alternatively there could be two cancel buttons, one to simply abort the process, and a second one to keep what has been downloaded so far.
It must keep already downloaded files in zip/non-zip folders on cancel (it save image by image on download).
- For non-zip: if you see temporary files like “xxx.download” or other dirty names folders after download done/cancel then report here. It must be clean on app restart too.
- For zip and non-zip: if you see broken image file (file contains non image data and can’t be opened) then report here.
- For zip: there are possible fatal use case with full zip-file content lost due edit outside of the app while downloading. But that’s ok.
I only see the temp files during zip download - upon pressing cancel, those temp files are deleted, but none of the downloaded images are saved. (This is what I am suggesting changing. Upon pressing cancel when downloading to zip files, the temp files should be processed to keep the images that have been downloaded that session.)
I can confirm - it’s not keep zip files in some use cases cause it run images fix too early (before save finished).