GitLab

License: MIT
Signed-off-by: Jeromy <jeromyj@gmail.com>

Instead of abusing a LsLink for non-directory objects [1].

[1]: https://github.com/ipfs/go-ipfs/pull/1348#discussion_r32680669

License: MIT
Signed-off-by: W. Trevor King <wking@tremily.us>

We don't want to prefix these results with the argument.  If there was
only one argument, the unprefixed results are still explicit.

License: MIT
Signed-off-by: W. Trevor King <wking@tremily.us>

Discussion with Juan on IRC ([1] through [2]) lead to this adjusted
JSON output.  Benefits over the old output include:

* deduplication (we only check the children of a given Merkle node
  once, even if multiple arguments resolve to that hash)

* alphabetized output (like POSIX's ls).  As a side-effect of this
  change, I'm also matching GNU Coreutils' ls output (maybe in POSIX?)
  by printing an alphabetized list of non-directories (one per line)
  first, with alphabetized directory lists afterwards.

[1]: https://botbot.me/freenode/ipfs/2015-06-12/?msg=41725570&page=5
[2]: https://botbot.me/freenode/ipfs/2015-06-12/?msg=41726547&page=5

License: MIT
Signed-off-by: W. Trevor King <wking@tremily.us>

This doesn't affect the text output, which was already using a
stringified name.  The earlier stringification does change the JSON
output from an enumeration integer (e.g. 2) to the string form
(e.g. "File").  If/when we transition to Merkle-object types named by
their hash, we will probably want to revisit this and pass both the
type hash and human-readable-but-collision-prone name on to clients.

License: MIT
Signed-off-by: W. Trevor King <wking@tremily.us>

Change the approach to the directory-header control so we can set the
Argument value in the JSON response.

Stripping the trailing newline from the JSON output is annoying, but
looking over [1] I saw no easy way to add a newline to the JSON
output.  And with the general framework that commands/ attempts to be,
it feels a bit funny to customize the JSON output for a command-line
program.  Perhaps a workable solution is to have the command-line
client append newlines to any output that otherwise lacks them?  But
that seems like a change best left to a separate series.

[1]: http://golang.org/pkg/encoding/json/

License: MIT
Signed-off-by: W. Trevor King <wking@tremily.us>

To be less confusing to newcomers (the IPFS filesystem isn't
Unix-specific anyway, and it isn't even very POSIX-specific [1,2,3]).
I'm a bit uncertain about having one name for users and another for
devs, but the consensus seems to be that mainaining two names is worth
the trouble [4].  We also kicked around:

* 'files' (plural),
* 'filesystem' (too long), and
* 'fs' (redundant after 'ipfs', even though IPFS isn't just about
  filesystems)

on IRC [5 through 6].  I wish there was a more evocative term.  I'm
never sure where "file" lands on the scale between "filesysytem",
"everything is a file", "a single chunk of data with an associated
inode".  But we can't think of anything better.

[1]: https://github.com/ipfs/go-ipfs/pull/1348#issuecomment-110529070
[2]: https://github.com/ipfs/go-ipfs/pull/1348#issuecomment-110529921
[3]: https://github.com/ipfs/go-ipfs/pull/1136/files#r29377283
  In my response to this (no longer visibile on GitHub):

  On Wed, Apr 29, 2015 at 01:30:04PM -0700, Juan Batiz-Benet wrote:
  > > +package fsnode
  >
  > i think this package should be called `unixfs` as that's the
  > abstraction that this is calling to.

  Will do, although I don't see what's especially Unix-y about these
  file nodes.

[4]: https://github.com/ipfs/go-ipfs/pull/1348#issuecomment-110529811
[5]: https://botbot.me/freenode/ipfs/2015-06-09/?msg=41428456&page=5
[6]: https://botbot.me/freenode/ipfs/2015-06-09/?msg=41430703&page=5

License: MIT
Signed-off-by: W. Trevor King <wking@tremily.us>

Folks operating at the Unix-filesystem level shouldn't care about that
level of Merkle-DAG detail.  Before this commit we had:

  $ ipfs unixfs ls /ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4/busybox
  /ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4/busybox:
  ... several lines of empty-string names ...

And with this commit we have:

  $ ipfs unixfs ls /ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4/busybox
  /ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4/busybox

I also reworked the argument-prefixing (object.Argument) in the output
marshaller to avoid redundancies like:

  $ ipfs unixfs ls /ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4/busybox
  /ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4/busybox:
  /ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4/busybox

As a side-effect of this rework, we no longer have the trailing blank
line that we used to have after the final directory listing.

The new ErrImplementation is like Python's NotImplementedError, and is
mostly a way to guard against external changes that would need
associated updates in this code.  For example, once we see something
that's neither a file nor a directory, we'll have to update the switch
statement to handle those objects.

License: MIT
Signed-off-by: W. Trevor King <wking@tremily.us>

This is similar to 'ipfs ls ...', but it:

* Lists file sizes that match the content size:

    $ ipfs --encoding=json unixfs ls /ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4
    {
      "Objects": [
        {
          "Argument": "/ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4",
          "Links": [
            {
              "Name": "busybox",
              "Hash": "QmPbjmmci73roXf9VijpyQGgRJZthiQfnEetaMRGoGYV5a",
              "Size": 1947624,
              "Type": 2
            }
          ]
        }
      ]
    }
    $ ipfs cat /ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4/busybox | wc -c
    1947624

  'ipfs ls ...', on the other hand, is using the Merkle-descendant
  size, which also includes fanout links and the typing information
  unixfs objects store in their Data:

    $ ipfs --encoding=json ls /ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4
    {
      "Objects": [
        {
          "Hash": "/ipfs/QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4",
          "Links": [
            {
              "Name": "busybox",
              "Hash": "QmPbjmmci73roXf9VijpyQGgRJZthiQfnEetaMRGoGYV5a",
              "Size": 1948128,
              "Type": 2
            }
          ]
        }
      ]
    }

* Has a simpler text output corresponding to POSIX ls [1]:

    $ ipfs unixfs ls /ipfs/QmV2FrBtvue5ve7vxbAzKz3mTdWq8wfMNPwYd8d9KHksCF/gentoo/stage3/amd64/2015-04-02
    bin
    dev
    etc
    proc
    run
    sys
    $ ipfs ls /ipfs/QmV2FrBtvue5ve7vxbAzKz3mTdWq8wfMNPwYd8d9KHksCF/gentoo/stage3/amd64/2015-04-02
    QmSRCHG21Sbqm3EJG9aEBo4vS7Fqu86pAjqf99MyCdNxZ4 1948183 bin/
    QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn 4       dev/
    QmUz1Z5jnQEjwr78fiMk5babwjJBDmhN5sx5HvPiTGGGjM 1207    etc/
    QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn 4       proc/
    QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn 4       run/
    QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn 4       sys/

  The minimal output allows us to start off with POSIX compliance and
  then add options (which may or may not be POSIX compatible) to
  adjust the output format as we get a better feel for what we need
  ([2] through [3]).

[1]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html
[2]: https://botbot.me/freenode/ipfs/2015-06-12/?msg=41724727&page=5
[3]: https://botbot.me/freenode/ipfs/2015-06-12/?msg=41725146&page=5

License: MIT
Signed-off-by: W. Trevor King <wking@tremily.us>