Ipfs-webui: Files: issues when browsing /ipfs/{cid}

Created on 7 Oct 2020  ยท  10Comments  ยท  Source: ipfs/ipfs-webui

Describe the bug
I am looking at the Apollo archive (listed in the explore tab) at this image (on my local gateway)

http://127.0.0.1:8080/ipfs/QmSnuWmxptJZdLJpKRarxBMS2Ju2oANVrgbr2xWbie9b2D/albums/QXBvbGxvIDEwIE1hZ2F6aW5lIDM1L1U=/21328560323_6b33f5d4c3_o.jpg

In the explore tab I also navigated to find the raw CID of the image, which is here (Qmdgqdddt3F2uszEaE7zph7kXbwHX3iTDCWeQjdtNGnQgz):

http://127.0.0.1:8080/ipfs/Qmdgqdddt3F2uszEaE7zph7kXbwHX3iTDCWeQjdtNGnQgz


Bug 1:

Using the Brose search bar up top for that CID gives:
image

The "Try downloading it instead." link correctly gives a .jpeg extension.


Bug 2:

BUT the ... More menu download yields a "Save As..." menu with a .txt file named the CID.

image


Bug 3:

I try to pin/unpin this to my node in the same menu, and receive an error:

image


Bug 4 :wink:

I can't find this on the GUI anywhere, though I am directed to by the issue template:

ATTACH LOGS

If possible:
1. Go to `Advanced` โ†’ `Open Logs Directory`
2. Find `*.log` files
3. Attach `error.log` and `combined.log` to this issue.

I only found the attached logs as I get the notification when _I run the application from a terminal_

info: [meta] logs can be found on ...../.config/IPFS Desktop


combined.log

2020-09-30T22:23:57.625Z info: [meta] logs can be found on /home/dan/.config/IPFS Desktop
2020-09-30T22:23:59.123Z info: [web ui] window ready
2020-09-30T22:23:59.125Z info: [web ui] navigate to /
2020-09-30T22:23:59.173Z info: [tray] starting
2020-09-30T22:23:59.233Z info: [tray] started
2020-09-30T22:23:59.234Z info: [ipfsd] start daemon STARTED
2020-09-30T22:24:00.988Z info: [daemon] PeerID is Qmb61NjeYWBAUHHfXdZQp2MED8XuXRWrRgrFDG4xtBTQvA
2020-09-30T22:24:00.989Z info: [daemon] Repo is at /home/dan/.ipfs
2020-09-30T22:24:00.999Z info: [ipfsd] start daemon FINISHED 1.7648615709999576s
2020-09-30T22:24:01.033Z error: [updater] Error: ENOENT: no such file or directory, open '/opt/IPFS Desktop/resources/app-update.yml'
2020-09-30T22:24:01.041Z info: [npm on ipfs] 1st time running and package is not installed
2020-09-30T22:24:01.048Z info: [launch on startup] disabled
2020-09-30T22:25:04.825Z info: [web ui] window hidden
2020-09-30T22:25:09.306Z info: [ipfsd] stop daemon STARTED
2020-09-30T22:25:09.591Z info: [ipfsd] stop daemon FINISHED 0.2849655619999394s
2020-09-30T22:25:09.602Z info: [ipfsd] start daemon STARTED
2020-09-30T22:25:12.081Z info: [daemon] PeerID is Qmb61NjeYWBAUHHfXdZQp2MED8XuXRWrRgrFDG4xtBTQvA
2020-09-30T22:25:12.082Z info: [daemon] Repo is at /home/dan/.ipfs
2020-09-30T22:25:12.082Z info: [ipfsd] start daemon FINISHED 2.4798767619999125s
2020-09-30T22:25:19.510Z info: [web ui] navigate to /
2020-09-30T22:25:21.520Z info: [web ui] navigate to /peers
2020-09-30T22:25:27.988Z info: [web ui] navigate to /settings
2020-09-30T22:25:35.808Z info: [web ui] window hidden
2020-09-30T22:25:39.293Z info: [ipfsd] stop daemon STARTED
2020-09-30T22:25:39.339Z info: [ipfsd] stop daemon FINISHED 0.04602136099990457s
2020-10-06T00:46:25.316Z info: [meta] logs can be found on /home/dan/.config/IPFS Desktop
2020-10-06T00:46:26.913Z info: [web ui] window ready
2020-10-06T00:46:26.914Z info: [web ui] navigate to /
2020-10-06T00:46:26.973Z info: [tray] starting
2020-10-06T00:46:27.028Z info: [tray] started
2020-10-06T00:46:27.028Z info: [ipfsd] start daemon STARTED
2020-10-06T00:46:29.373Z info: [daemon] PeerID is Qmb61NjeYWBAUHHfXdZQp2MED8XuXRWrRgrFDG4xtBTQvA
2020-10-06T00:46:29.374Z info: [daemon] Repo is at /home/dan/.ipfs
2020-10-06T00:46:29.374Z info: [ipfsd] start daemon FINISHED 2.3457141930013896s
2020-10-06T00:46:29.400Z error: [updater] Error: ENOENT: no such file or directory, open '/opt/IPFS Desktop/resources/app-update.yml'
2020-10-06T00:46:29.408Z info: [ipfs on path] no action taken
2020-10-06T00:46:29.410Z info: [launch on startup] disabled
2020-10-07T01:50:24.447Z info: [meta] logs can be found on /home/dan/.config/IPFS Desktop
2020-10-07T01:50:25.710Z info: [web ui] window ready
2020-10-07T01:50:25.711Z info: [web ui] navigate to /
2020-10-07T01:50:25.811Z info: [tray] starting
2020-10-07T01:50:25.860Z info: [tray] started
2020-10-07T01:50:25.861Z info: [ipfsd] start daemon STARTED
2020-10-07T01:50:26.143Z info: [daemon] removing api file
2020-10-07T01:50:27.602Z info: [ipfsd] start daemon FINISHED 1.7408583110049367s
2020-10-07T01:50:27.631Z error: [updater] Error: ENOENT: no such file or directory, open '/opt/IPFS Desktop/resources/app-update.yml'
2020-10-07T01:50:27.636Z info: [ipfs on path] no action taken
2020-10-07T01:50:27.639Z info: [launch on startup] disabled
2020-10-07T02:14:46.318Z info: [web ui] launching web ui
2020-10-07T02:22:28.788Z info: [web ui] window hidden
2020-10-07T02:22:36.966Z info: [web ui] launching web ui
  ```
</details>
<details>
  <summary>error.log</summary>

2020-09-30T22:24:01.033Z error: [updater] Error: ENOENT: no such file or directory, open '/opt/IPFS Desktop/resources/app-update.yml'
2020-10-06T00:46:29.400Z error: [updater] Error: ENOENT: no such file or directory, open '/opt/IPFS Desktop/resources/app-update.yml'
2020-10-07T01:50:27.631Z error: [updater] Error: ENOENT: no such file or directory, open '/opt/IPFS Desktop/resources/app-update.yml'
```

kinbug help wanted exintermediate P2 arescreefiles effordays

Most helpful comment

Thank you @NukeManDan!
In the future, please fill each bug in separate issue, even if its tiny!, it makes easier for us to triage :-)

Did a quick analysis of bug 1:

Problem occurs because ipfs-webui does not do full-blown proper content-type sniffing, it only looks at filename https://github.com/ipfs-shipyard/ipfs-webui/blob/95319bab6e1d915bff1d83717752ec2f8312f715/src/files/file-preview/FilePreview.js#L21

That is why opening https://webui.ipfs.io/#/ipfs/Qmdgqdddt3F2uszEaE7zph7kXbwHX3iTDCWeQjdtNGnQgz fails because it has no file extension to work with.

Quick fix would be to add ?filename=name.jpg, but that works only when we know the type of file.

More robust fix would be to detect situation like this, read first n bytes via ipfs.cat and pass them to content-type sniffer.
Prior art is already in the basic gateway implemented in js-ipfs:

All 10 comments

I figured these were minor enough as I discovered them to group here, I can parse into separate issues if you see fit ๐Ÿ™๐Ÿผ

(Transferring issue to webui repo.)

Thanks, @nukemandan. We'll investigate these in more depth in our next weekly triage.

Some notes for triage:

  • Can confirm similar experience to @NukeManDan on his bugs 1-3 above (for me, Mac in latest 0.13.0 release). @rafaelramalho19 and/or @lidel, can you please do some investigation when you get the time?

  • For bug 4, these instructions didn't make sense to @NukeManDan because he's running a Linux that doesn't give him the system tray menu.

RE: bug 1 - this is expected behaviour I think, as a raw CID does not contain file header information like a file that has human readable MFS extensions... I would think it possible to auto detect this in browser, I know that on Linux at least, with no extension the OS usually detects the file type somehow...

RE: bug 4 - I actually _do_ have the tray icon! But I did not realize that was where I was to look! I was only trying to find this in the full window GUI.

The error logs seem to indicate updating automatically is not working, possibly only due to the updater not being installed correctly by my or the .deb package? (Revision 7a8f695)

I updated to v0.13.0 via the .deb release and have the same updating error. I can port this to a new issue if you like ๐Ÿ˜

@NukeManDan - An updating issue would be specific to Desktop, so if you're able to open an issue in https://github.com/ipfs-shipyard/ipfs-desktop with any relevant details, that would be very helpful.

Thank you @NukeManDan!
In the future, please fill each bug in separate issue, even if its tiny!, it makes easier for us to triage :-)

Did a quick analysis of bug 1:

Problem occurs because ipfs-webui does not do full-blown proper content-type sniffing, it only looks at filename https://github.com/ipfs-shipyard/ipfs-webui/blob/95319bab6e1d915bff1d83717752ec2f8312f715/src/files/file-preview/FilePreview.js#L21

That is why opening https://webui.ipfs.io/#/ipfs/Qmdgqdddt3F2uszEaE7zph7kXbwHX3iTDCWeQjdtNGnQgz fails because it has no file extension to work with.

Quick fix would be to add ?filename=name.jpg, but that works only when we know the type of file.

More robust fix would be to detect situation like this, read first n bytes via ipfs.cat and pass them to content-type sniffer.
Prior art is already in the basic gateway implemented in js-ipfs:

Happy to craft separate issues referencing this one and closing it if that helps @lidel ๐Ÿ™‡๐Ÿผ

For this specific case I think we can keep them grouped together (renamed the issue to reflect that) :+1:
Note this week is a bit busy for the team, but we will do our best to triage this properly next week.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

TitaniumCoder477 picture TitaniumCoder477  ยท  5Comments

olizilla picture olizilla  ยท  4Comments

shanelau picture shanelau  ยท  4Comments

dsvi picture dsvi  ยท  5Comments

royforu picture royforu  ยท  4Comments