Resume File System Access batch file downloads #149

New issue

Closed

opened 2026-08-10 12:10:02 +00:00 by aaperis · 0 comments

aaperis commented

2026-08-10 12:10:02 +00:00

(Migrated from github.com)

Please describe the feature

As a user, I want to be able to resume downloading files to my local disk so that downloading large amount of files can be done without having to do tedious manual work if interrupted.

Detailed description

This is a follow-up to #118.
Users should be able to choose the same local folder to save their files to and the webapp should be able to pick up from where the previous download left off.

Use the existing /api/files/:fileId backend route which already supports HTTP resume semantics like Range, If-Range, ETag, etc, so this issue concerns client side code.
Do not overwrite completed files
Resume incomplete files
Do not resume incomplete files if the user's submitted c4gh pub key has changed between the two sessions (using our server's API ETag ensures this).
We can read-off partial file size from local files but we also need to store state info like ETag (necessary for the correct c4gh pub key) and completed/incomplete status of files. One idea for storing these metadata could be in the form of a hidden file .<datasetname-metadata> inside the parent folder of the download. This would make the download session persistent upon user login/logout.

Additional context

The idea of saving incomplete files with .part extension and then renaming them upon completion seems not feasible for now, because the move action of the FileSystemAccess API is only partially supported among different browsers (see here).

## Please describe the feature As a user, I want to be able to resume downloading files to my local disk so that downloading large amount of files can be done without having to do tedious manual work if interrupted. ## Detailed description This is a follow-up to #118. Users should be able to choose the same local folder to save their files to and the webapp should be able to pick up from where the previous download left off. - Use the existing `/api/files/:fileId` backend route which already supports HTTP resume semantics like Range, If-Range, ETag, etc, so this issue concerns client side code. - [ ] Do not overwrite completed files - [ ] Resume incomplete files - [ ] Do not resume incomplete files if the user's submitted c4gh pub key has changed between the two sessions (using our server's API ETag ensures this). - [ ] We can read-off partial file size from local files but we also need to store state info like ETag (necessary for the correct c4gh pub key) and completed/incomplete status of files. One idea for storing these metadata could be in the form of a hidden file `.<datasetname-metadata>` inside the parent folder of the download. This would make the download session persistent upon user login/logout. ## Additional context - The idea of saving incomplete files with `.part` extension and then renaming them upon completion seems not feasible for now, because the `move` action of the FileSystemAccess API is only partially supported among different browsers (see [here](https://developer.mozilla.org/en-US/docs/Web/API/File_System_API#api.FileSystemHandle)).