Is your feature request related to a problem? Please describe.
Currently, when a download is paused or incomplete, Surge creates a .surge file. However, this file only contains the raw, incomplete binary data. The metadata required to resume the download (such as the source URL, total file size, ETag, chunk/range map, and referrers) is either stored elsewhere in a local database/cache or kept only in memory.
This means:
- If the local cache/database is cleared, the download cannot be resumed from the
.surge file.
- Incomplete downloads cannot be moved to another machine or shared with another user to resume from where it left off.
Describe the solution you'd like
I propose redefining the .surge file format to be a self-contained download package that embeds both the metadata and the incomplete binary payload.
By doing this, a .surge file becomes entirely portable. A user could send their incomplete large_video.mp4.surge file to a friend, and that friend could double-click it in Surge to immediately resume downloading the remaining bytes from the original source.
Suggested File Structure Layout
To keep things efficient and avoid reading the entire file into memory just to parse metadata, we could append a Metadata Footer at the very end of the .surge file (similar to how ZIP files or Android APKs work).
Is your feature request related to a problem? Please describe.
Currently, when a download is paused or incomplete, Surge creates a
.surgefile. However, this file only contains the raw, incomplete binary data. The metadata required to resume the download (such as the source URL, total file size, ETag, chunk/range map, and referrers) is either stored elsewhere in a local database/cache or kept only in memory.This means:
.surgefile.Describe the solution you'd like
I propose redefining the
.surgefile format to be a self-contained download package that embeds both the metadata and the incomplete binary payload.By doing this, a
.surgefile becomes entirely portable. A user could send their incompletelarge_video.mp4.surgefile to a friend, and that friend could double-click it in Surge to immediately resume downloading the remaining bytes from the original source.Suggested File Structure Layout
To keep things efficient and avoid reading the entire file into memory just to parse metadata, we could append a Metadata Footer at the very end of the
.surgefile (similar to how ZIP files or Android APKs work).