ipfs.files.exists?

[aphelionz]

Another possible "exists" request.

I'm working with ipfs.files.cat and I may have the need to detect whether a hash exists in the local repo before trying to get it from a gateway. Since the browser node isn't autoatically peering and retrieving files from the DHT yet (or I don't know how to manually implement it yet (or both)), I need to create a workflow that's something like:

1. Try to attempt to grab the content locally
2. Catch the exception and grab it from a dedicated gateway I have hosted on AWS

However, looking at the code for cat, I see the pull stream calls at the bottom:

        pull(
          exporter(hash, self._ipldResolver),
          pull.collect((err, files) => {
            if (err) {
              return callback(err)
            }
            callback(null, toStream.source(files[0].content))
          })
        )

I don't think that pull.colllect call is fired if the hash doesn't exist, so when I create a promise chain like below, it never fails or resolves.

        this.ipfs.files.cat(e.detail)
          .then(this._processObjectStream)
          .then(this._fireBodyEvent.bind(this, "file-read"))
          .catch(this._getFileFromServer.bind(this));

Not sure exactly how to proceed. Any advice or workaround is appreciated. Thank you!

[daviddias]

@aphelionz I believe that is what ipfs refs local is for, although it just lists the hashes of objects, it has no notion of 'files'.

» ipfs refs local --help
USAGE
  ipfs refs local - List all local references.

SYNOPSIS
  ipfs refs local

DESCRIPTION

  Displays the hashes of all local objects.

A files.exists might be indeed useful, but also misleading, it should include options for:

• local
• check only root (avoid recursively checking all the leafs)

Please consider making a proposal to https://github.com/ipfs/interface-ipfs-core/tree/master/API/files with a PR.

[aphelionz]

Right, I'm still getting the nomenclature right. Checking to see if the hash exists locally should be enough. Let me try with that and I'll report back and close the issue if it suffices.

[aphelionz]

@diasdavid Though, should the pull() function have an error state that throws and therefore doesnt break the promise chain? Or am I using that / reading that incorrectly?

[daviddias]

@aphelionz apologize for the delay. The reason is that right now we don't have timeouts intentionally, which means that the pull/promise chain will wait forever.

See: https://github.com/ipfs/interface-ipfs-core/issues/58

Did you consider to add this call to the interface definition?

[daviddias]

Created the issue to get tracked there: ipfs-inactive/interface-js-ipfs-core#146