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

Upload via WebUI (ipfs.files.write --create) produces different hash than CLI (ipfs.add) #676

Closed
lidel opened this issue Jun 6, 2018 · 2 comments

Comments

@lidel
Copy link
Member

lidel commented Jun 6, 2018

(Originally reported in ipfs-inactive/support#45, today it was raised on irc)

Discrepancy between ipfs.add and ipfs.files.write --create was discussed and explained in ipfs-inactive/support#45, this issue is only about solving UX problem in WebUI.

How to Reproduce

  1. Download QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR and save it as file.jpg
  2. Add it back via CLI (ipfs add file.jpg
  3. Open Files screen in old webui
  4. Upload file.jpg
  5. Right-click on it and select Copy hash

Current behavior

Copied value is QmWKsy9a3AU3Yn9SDuqUFNMnxFnsGq5KzkKgZREsr1cifv and not QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR.

In short ipfs.files.write --create (used by old webui) produces different hash than ipfs.add, for reasons notes in ipfs-inactive/support#45 (comment):

The hashes are different because ipfs files write uses different linking structure than ipfs add. ipfs files write's linking structure is optimized for random seeking and writing after initial creation and ipfs add structure is optimized for reduction of link count.

Underling data is still deduplicated as they use the same chunking, AFAIK.

ipfs.files.write --create

$ curl -s https://ipfs.io/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR | ipfs files write --create /files.write.jpg

$ ipfs files stat /files.write.jpg
QmWKsy9a3AU3Yn9SDuqUFNMnxFnsGq5KzkKgZREsr1cifv
Size: 119762
CumulativeSize: 119832
ChildBlocks: 1

Expected behavior

Most of users assume that hash will not change if the upload is done with "default settings of default tools". Value returned by ipfs.add sets expectation for entire ecosystem.

AFAIK an easy fix would be to switch WebUI's upload to use ipfs.add and then ipfs.files.cp:

ipfs.add --pin=false && ipfs.files.cp

(I think we don't want to pin, as presence in MFS will be enough to protect files from GC)

$ curl -s https://ipfs.io/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR | ipfs add
added QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR

$ ipfs files cp /ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR /add.jpg

$ ipfs files stat /add.jpg
QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR
Size: 119762
CumulativeSize: 119776
ChildBlocks: 0
Type: file
@hacdias
Copy link
Member

hacdias commented Jul 9, 2018

This is fixed on revamp branch. Can we close this? I also feel that revamp is coming closer to master in terms of features.

@lidel
Copy link
Member Author

lidel commented Jul 10, 2018

👌

@lidel lidel closed this as completed Jul 10, 2018
lidel added a commit to jay-dee7/ipfs-webui that referenced this issue Aug 26, 2020
The way import via Webui works is:
1. `ipfs add` produces CID
2. we create a reference to that CID in MFS

We do this to produce the same CID as regular ipfs add from CLI would
do, mainly to avoid issue described in:
ipfs#676
jessicaschilling added a commit that referenced this issue Aug 26, 2020
* [WIP] Feature - CLI Tutor Mode

Signed-off-by: Jasdeep Singh <jasdeepsingh.uppal@gmail.com>

* Update src/components/cli-tutor-mode/CliTutorMode.js

Co-authored-by: Jessica Schilling <jessica@protocol.ai>

* Update src/components/cli-tutor-mode/CliTutorMode.js

Co-authored-by: Jessica Schilling <jessica@protocol.ai>

* Align fix: cli tutor modal buttons

Signed-off-by: Jasdeep Singh <jasdeepsingh.uppal@gmail.com>

* Fix: added compatibility with ApiAddressForm component

Signed-off-by: Jasdeep Singh <jasdeepsingh.uppal@gmail.com>

* Fix: added bundle-reactx pattern and en translation keys

Signed-off-by: Jasdeep Singh <jasdeepsingh.uppal@gmail.com>

* i18n text change

* Standardize i18n and visual style on Settings page

* Text tweak; replace CliTutorMode.css with tachyons equivalents

* Left-justify shell content in modals for consistency

* Tidy visual presentation of modals

* Size tweak for icon on Files page

* Use StrokeCode instead of CopyIcon, adjust text accordingly

* Lighten icon on settings page explainer text

* Margin consistency

* Update src/bundles/files/consts.js

Co-authored-by: Marcin Rataj <lidel@lidel.org>

* Move lh-copy so doesn't fubar checkbox styling

* Fix: Close modal on copy to clipboard

Signed-off-by: Jasdeep Singh <jasdeepsingh.uppal@gmail.com>

* Fix: rename file command

Signed-off-by: Jasdeep Singh <jasdeepsingh.uppal@gmail.com>

* Fix: delete file by filepath and added type information for cliCommandList

Signed-off-by: Jasdeep Singh <jasdeepsingh.uppal@gmail.com>

* fix: whitespace in ipfs files rm

Without this below will fail:
ipfs files rm -r /test/white space/flowers.jpeg

* fix: remove UPDATE_API_SERVER_ADDRESS

This removed CLI tutor from "API Adddress" selector because it does not
make sense:

"API ADDRESS" section does not change the config of IPFS node, but
defines the API which WebUI will use when connecting to the node.

* fix: eslint

* fix: remove angle brackets from i18n strings

text between < and > won't be translated because Transifex blackboxes
HTML tags, it is better to remove it

* Move cliModal i18n keys into app.json

See https://react.i18next.com/guides/multiple-translation-files

* Move copyCommand & relevant close i18n keys into app.json

* fix: include files cp step

The way import via Webui works is:
1. `ipfs add` produces CID
2. we create a reference to that CID in MFS

We do this to produce the same CID as regular ipfs add from CLI would
do, mainly to avoid issue described in:
#676

* refactor: make it easier to support path

Right now CLI tutor defaults to MFS root at /,
this makes it easier to include current path in the future.

Co-authored-by: Jessica Schilling <jessica@protocol.ai>
Co-authored-by: Marcin Rataj <lidel@lidel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants