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

Add option to send directory as stream of compressed tarball #141

Open
2 tasks done
Jacalz opened this issue Feb 5, 2024 · 0 comments
Open
2 tasks done

Add option to send directory as stream of compressed tarball #141

Jacalz opened this issue Feb 5, 2024 · 0 comments
Labels
enhancement New feature or request performance Improve application performance
Milestone

Comments

@Jacalz
Copy link
Owner

Jacalz commented Feb 5, 2024

Checklist

  • I have searched the issue tracker for open issues that relate to the same feature, before opening a new one.
  • This issue only relates to a single feature. I will open new issues for any other features.

Is your feature request related to a problem?

The built in directory send support in the Wormhole implementation uses .zip for directories and has to save it to a local file both when sending and receiving. This can be problematic as in #93 when the file is stored in memory and thte file size is larger than the available memory and can also be a performance bottleneck.

Describe the solution you'd like to see.

Provide an option to select a Directory transfer mode with a choice of either Compatability (standard) or Streaming. Choosing the latter should pop up a warning saying that other clients and older Rymdport versions only will get a .tar.gz file that has to be extracted manually. This option should then send the directory as a regular file send and automaticlly extract files of the same type (we need something more than just looking at the filetype there).

The implementation can likely use https://github.com/rymdport/archive. We should evaluate if it is faster to use Zstandard or Gzip for compression (for the latter, pgzip will likely be the fastest).

@Jacalz Jacalz added enhancement New feature or request performance Improve application performance labels Feb 5, 2024
@Jacalz Jacalz added this to the v3.7.0 milestone Feb 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request performance Improve application performance
Projects
None yet
Development

No branches or pull requests

1 participant