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.

Sign up for GitHub

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

Jump to bottom

ipfs pin ls <hash> fetches the object from the network #3419

Closed
hsanjuan opened this issue Nov 24, 2016 · 0 comments
Closed

ipfs pin ls <hash> fetches the object from the network #3419

hsanjuan opened this issue Nov 24, 2016 · 0 comments
Labels
kind/bug A bug in existing code (including security flaws)

Comments

@hsanjuan
Copy link
Contributor

Version information: master

Type: Bug

Priority: P5

Description:

ipfs pin ls seems by all means a local operation, but when the daemon is running and a <ipfs_hash> argument is passed, it will request blocks from the network when it does not know the hash. i.e:

ipfs pin ls QmXja3KdmLxxS5F7SxASEB1Kg9AbkQ9PZpF67hyauHEgZa

This has side effects like:

  • Hanging when a hash is not pinned instead of simply showing that it is not pinned locally
  • Fetching objects that the user don't expect to be fetched (and thus [probably] making them available to others). Really bad if you're checking for content you don't want to have. Also, it happens silently.
  • If a user wants to check if a hash is pinned, it forces the user to do ipfs pin ls and then filter out the results, as pin ls without arguments seems to run locally entirely.
@Kubuxu Kubuxu added status/deferred Conscious decision to pause or backlog help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) labels Nov 24, 2016
hsanjuan added a commit that referenced this issue Nov 24, 2016
@hsanjuan
Issue #3419: Do not recursively resolve DAG just to obtain a CID
ac054f3 
License: MIT
Signed-off-by: Hector Sanjuan <code@hector.link>
@hsanjuan hsanjuan added status/in-progress In progress and removed help wanted Seeking public contribution on this issue labels Nov 24, 2016
@hsanjuan hsanjuan mentioned this issue Nov 24, 2016
Merged
whyrusleeping added a commit that referenced this issue Nov 25, 2016
@whyrusleeping
Merge pull request #3420 from ipfs/fix/pin-ls
38d009d 
Issue #3419: Do not recursively resolve DAG just to obtain a CID
@Kubuxu Kubuxu removed status/deferred Conscious decision to pause or backlog status/in-progress In progress labels Nov 25, 2016
@ghost ghost mentioned this issue Dec 23, 2016
Closed
liliuhai added a commit to peersafe/go-ipfs that referenced this issue Dec 26, 2016
@liliuhai
Merge commit 'f81cccc3fc927f592e6655fe280aa7f0c7d885c6' into HEAD
a6b8abe 
* commit 'f81cccc3fc927f592e6655fe280aa7f0c7d885c6':
  bubble up go-datastore deps
  completely remove go-key dep
  Add dag and stat
  Add test_go_fmt to makefile
  Remove trailing new-line from pbdagreader.go
  Lowercase error messages
  Issue ipfs#3419: Do not recursively resolve DAG just to obtain a CID
  Send empty struct to pubsub cmd output to flush
  use floodsub version 0.8.1
  Remove NewRSNCFromBytes and use NewDagReader for recursive reading
  cleanup bitswap and handle message send failure slightly better
  Cleanup gofmt in fuse lib
  Update go-libp2p across codebase
  Add sharness test for raw node fetch
  Create bufDagReader
  Move proto-dag reader to separate file and change name
  Make unixio.DagReader an interface

# Conflicts:
#	exchange/bitswap/network/ipfs_impl.go
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/bug A bug in existing code (including security flaws)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@hsanjuan @Kubuxu