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
{{ message }}
Repository navigation
File → menu → Download buffers entire file into a blob #1887
Hi @ZeroCool22! Thanks for the bug report. I could not reproduce it, which makes me think it may be related to RAM memory. I see you have 32 GB of RAM and that it reaches ~60% usage before crashing. How large is the file? Could you also try checking the developers console when it happens (CTRL+SHIFT+I)?
Hi @ZeroCool22! Thanks for the bug report. I could not reproduce it, which makes me think it may be related to RAM memory. I see you have 32 GB of RAM and that it reaches ~60% usage before crashing. How large is the file? Could you also try checking the developers console when it happens (CTRL+SHIFT+I)?
@ZeroCool22 thank you for recording the demo, it is very useful.
We will fix this, but for now you need to use a workaround: avoid using the "Download" ("Descarga") action from menu, and click on "Local gateway" instead:
Let us know if this works with your 7GB file.
@hacdias my understanding of the problem is that we need to change how "Download" context action of a single file is implemented on the Files screen. It reads correct URL from doFilesDownloadLink but then downloads it using downloadFile function from src/files/download-file.js, which buffers the entire thing in memory to construct a blob:.
I believe creating a blob via window.URL.createObjectURL in downloadFile was necessary because we did not have ?download=true four years ago (was introduced in 2020 in ipfs/kubo#7677), and we also displayed progress bar or something.
Today it is not necessary, and as we can see harms UX when a big file is downloaded. We should remove blob freation and leverage regular URL with added download=true parameter instead. Code for tracking download progress also should be removed – browser will handle that.
@lidel I think one of the issues is the directory: there's no way of downloading a directory via the gateway and the API is POST only (unless that changed recently)
@hacdias afaik /api/v0/get is also exposed on Gateway port, and there it should accept GET (POST restriction applies only to the RPC API port).
I think is fine to use that until we have a better way for fetching directories on Gateways.
Activity
hacdias commentedon Jan 10, 2022
Hi @ZeroCool22! Thanks for the bug report. I could not reproduce it, which makes me think it may be related to RAM memory. I see you have 32 GB of RAM and that it reaches ~60% usage before crashing. How large is the file? Could you also try checking the developers console when it happens (CTRL+SHIFT+I)?
ZeroCool22 commentedon Jan 10, 2022
Here you go:
https://streamable.com/u0kchy
ZeroCool22 commentedon Jan 11, 2022
No help?
I really want to use IPFS... :(
lidel commentedon Jan 11, 2022
@ZeroCool22 thank you for recording the demo, it is very useful.
We will fix this, but for now you need to use a workaround: avoid using the "Download" ("Descarga") action from menu, and click on "Local gateway" instead:
Let us know if this works with your 7GB file.
@hacdias my understanding of the problem is that we need to change how "Download" context action of a single file is implemented on the Files screen. It reads correct URL from
doFilesDownloadLinkbut then downloads it usingdownloadFilefunction from src/files/download-file.js, which buffers the entire thing in memory to construct ablob:.I believe creating a blob via
window.URL.createObjectURLindownloadFilewas necessary because we did not have?download=truefour years ago (was introduced in 2020 in ipfs/kubo#7677), and we also displayed progress bar or something.Today it is not necessary, and as we can see harms UX when a big file is downloaded. We should remove blob freation and leverage regular URL with added
download=trueparameter instead. Code for tracking download progress also should be removed – browser will handle that.Will you have time to submit a fix?
[-][/-][+][/+]hacdias commentedon Jan 14, 2022
@lidel I think one of the issues is the directory: there's no way of downloading a directory via the gateway and the API is POST only (unless that changed recently)
Ref ipfs/kubo#7746
lidel commentedon Jan 16, 2022
@hacdias afaik
/api/v0/getis also exposed on Gateway port, and there it should accept GET (POST restriction applies only to the RPC API port).I think is fine to use that until we have a better way for fetching directories on Gateways.
ipfs-gui-bot commentedon Dec 9, 2022
🎉 This issue has been resolved in version 2.21.0 🎉
The release is available on GitHub release
Your semantic-release bot 📦🚀