A way to list all objects stored in the repo

[mitar]

Version information:

go-ipfs version: 0.4.5-
Repo version: 5
System version: amd64/darwin
Golang version: go1.7.4

Type: Feature

Priority: P2

Description:

It would be great to be able to list all the objects in the repo.

I can use:

$ ipfs stats repo
NumObjects 	 996591
RepoSize 	 12267396749
RepoPath 	 /Users/user/.ipfs
Version 	 fs-repo@5

To see that I have 996591 objects. But how can I know which ones are that so that I could understand where is this number coming from.

I tried using ipfs-see-all but it does not work with my version of IPFS (whyrusleeping/ipfs-see-all#3) and also it seems it does not just list all objects.

So I propose ipfs repo ls or something. :-)

[Kubuxu]

ipfs refs local should give you want you want.

[mitar]

Oh. I was reading ipfs refs help output but I didn't so the thing at the end.

This is completely different from other commands and subcommands where you have ipfs command subcommand structure. I didn't know that command can take arguments in such case, or that even command which takes arguments can also have subcommands. This is confusing.

[whyrusleeping]

@mitar its technically implemented as a subcommand, but the way to look at it is that 'local' is just a special argument for ipfs refs. 'local' could be an alias to a node with links to every object in your local repo

[mitar]

I mean how this is internally. But it was really impossible to find. I checked refs, looked at the first line description, and moved on. No idea that I should also check at the end of the help page.

Also, thing like ipfs refs local --format '<src> <dst> <linkname>' does not really change any output. So the rest of the help page and arguments to refs do not really apply?

I think it would be much better if this would be ipfs refs ls and ipfs refs local. Should I open a new issue with this proposal?

[whyrusleeping]

We can rework the local subcommand to actually just be a special cased argument of ipfs refs

[Kubuxu]

This will change HTTP API sematic.

[mitar]

I just worry that it will be hard to find this if it is somewhere hidden under refs.

Or maybe we should just change the description so that refs can return lists for addresses and special groups of addresses. Or something.

[whyrusleeping]

@mitar its in the ipfs refs helptext. What do you mean by hard to find?

[mitar]

I mean, if I do:

$ ipfs refs --help
USAGE
  ipfs refs <ipfs-path>... - List links (references) from an object.

I see that this is not a command to list all objects in my current repo.

$ ipfs repo --help
USAGE
  ipfs repo - Manipulate the IPFS repo.

SYNOPSIS
  ipfs repo

DESCRIPTION

  'ipfs repo' is a plumbing command used to manipulate the repo.

SUBCOMMANDS
  ipfs repo fsck    - Remove repo lockfiles.
  ipfs repo gc      - Perform a garbage collection sweep on the repo.
  ipfs repo stat    - Get stats for the currently used repo.
  ipfs repo verify  - Verify all blocks in repo are not corrupted.
  ipfs repo version - Show the repo version.

  Use 'ipfs repo <subcmd> --help' for more information about each command.

OK, no command to list everything in my current repo.

And ipfs --help also does not list it.

So, it is hard to find. It is just surprising that a command has both subcommands and also works on its own. Most other commands I have looked at (like repo above) does not have that. So one does not think about going to the end of the help to read that there are subcomands. And List links (references) from an object does not say anything about working with a repo as well, or non-objects, or having subcommands.

This is just my experience as somebody who is not familiar with IPFS. Once you know where to find the command, it does not really matter where it is. But it was hard for me to find it with common strategies I use (and which worked for all other commands).

Also interesting is that refs is not listed in API docs. Only refs local. This is again a consequence of this strange exception here.

[whyrusleeping]

We could probably add ipfs repo ls, that should make things more discoverable maybe?

[mitar]

That would also be good, yes.

[miraclx]

@mitar

While this doesn't work;

ipfs refs local --format '<src> <dst> <linkname>'

You can, however, pipe the output of refs local back into refs since that collects input from stdin

ipfs refs local | ipfs refs --format '<src> <dst> <linkname>'

Or, with a better format

ipfs refs local | ipfs refs -u --format '<src> -> <dst> | <linkname>'

[mitar]

Awesome. But I think this issue transformed into "discoverability of this feature" issue.