Skip to content

File → menu → Download buffers entire file into a blob #1887

Closed

Description

@ZeroCool22
  • OS: Windows 10 x64
  • Version of IPFS Desktop [0.18.1]

Describe the bug

https://streamable.com/9z175t

To Reproduce
Steps to reproduce the behavior:

  1. Go to the file
  2. Click on more
  3. Scroll down to Download
  4. Blank Screen after some seconds.

Log files:

combined.log
error.log

PD: I tried reinstalling, but same problem.

Activity

  1. hacdias commented on Jan 10, 2022

    @hacdias
    Member

    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)?

  2. deleted a comment from on Jan 10, 2022
  3. ZeroCool22 commented on Jan 10, 2022

    @ZeroCool22
    Author

    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)?

    Here you go:

    https://streamable.com/u0kchy

  4. ZeroCool22 commented on Jan 11, 2022

    @ZeroCool22
    Author

    No help?

    I really want to use IPFS... :(

  5. lidel commented on Jan 11, 2022

    @lidel
    Contributor

    @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:

    2022-01-11_23-25

    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.

    Will you have time to submit a fix?

  6. changed the title [-][/-] [+][/+] on Jan 11, 2022
  7. transferred this issue fromipfs/ipfs-desktopon Jan 11, 2022
  8. added
    kind/bugA bug in existing code (including security flaws)
    P1High: Likely tackled by core team if no one steps up
    on Jan 11, 2022
  9. deleted a comment from welcome on Jan 11, 2022
  10. hacdias commented on Jan 14, 2022

    @hacdias
    Member

    @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

  11. lidel commented on Jan 16, 2022

    @lidel
    Contributor

    @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.

  12. added
    status/blockedUnable to be worked further until needs are met
    on Feb 18, 2022
  13. Repository owner moved this from To do to Done in IPFS-GUI (PL EngRes)on Nov 22, 2022
  14. ipfs-gui-bot commented on Dec 9, 2022

    @ipfs-gui-bot
    Collaborator

    🎉 This issue has been resolved in version 2.21.0 🎉

    The release is available on GitHub release

    Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P1High: Likely tackled by core team if no one steps uparea/screen/filesIssues related to Files screenkind/bugA bug in existing code (including security flaws)releasedstatus/blockedUnable to be worked further until needs are met

Type

No type

Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions