files.add to object.get to object.put: unexpected EOF

[nycoliver]

ipfs.add an file, ipfs.object.get the hash, then ipfs.object.put the object. When I try to cat the object I see unexpected EOF. Am I doing something wrong?

const ipfs = window.IpfsApi();
var bs58 = require('bs58');

// AddFromURL for ease of example but this happens with normal add as well.
// Also tested in node env and with other files, same error.
ipfs.util.addFromURL('https://avatars0.githubusercontent.com/u/2553061', function(err, res) {
  console.log(err, res)
  var hash = res[res.length-1].path
  ipfs.object.get(hash, function(err, object) {
    ipfs.object.put(object, function(err, res) {
      console.log(err, res)
      var objectHash = bs58.encode(object.multihash()).toString()
      console.log(objectHash)
      // http://localhost:8080/ipfs/QmZE6nF5xV8vnvFM7KB4WLzjdeJsvyfE1aGGm5JpGCRyhJ
      // returns internalWebError: unexpected EOF
    })
  })
})

[dignifiedquire]

See #370 (comment). The gist is, you need to put valid DAG objects in if you are using object.put.

[victorb]

@dignifiedquire So, as I see it, @nycoliver is adding a file from an url, gets the hash from the results and does ipfs.object.get with the hash (which should return a valid DAG object) and then ipfs.object.put with the very same object. Not sure what the use case is, but in my mind, this should work. Exactly like doing ipfs object get Qme76wbzPMhX8iANkuZ9aAp6UoGDZqwX1VKaSCFguAb2gx | ipfs object put for example, which should return the same hash.

[dignifiedquire]

@victorbjelkholm yes you are right, I misread the code and thought the object.put happened before the object.get

It seems this doesn't work on the cli either, so this should be moved to go-ipfs.

$ ipfs add myfile.txt
  <hash>
$ ipfs object get <hash> | ipfs object put
  <hash2>

Opening the browser at http://localhost:8080/ipfs/<hash2> will result in the same internalWebError.

[daviddias]

This seems more like a error in go-ipfs. Do note though that an object is not a file, and the IPFS gateway is really good at loading files. //cc @whyrusleeping

[nginnever]

I got internalWebError once but now i'm getting on v0.4.2 and go-ipfs v0.4.4-dev seeker can't seek from the gateway.

I've noticed that this seems to be a problem when an object has links. First inclination is that there is some encoding problem with object get.

On ipfs add <data>... ipfs object get <hash> | ipfs object put

localhost:8080/ipfs/<object put hash>

Think I have narrowed this down to a bug with the seeker implementation in go-ipfs.

I am able to successfully add -> get -> put as long as the dagNode doesn't have links to seek.

[whyrusleeping]

Yeah, the fact that ipfs object get X | ipfs object put doesnt result in a hash of X is a bug. It has to do with binary data in the json encoding as far as I can tell.

[nginnever]

i altered the data field in ipfs object get to a base64 encoded string here https://github.com/ipfs/go-ipfs/blob/dcfd842d8323e8d093a105e65f85c90d7bded7c0/core/commands/object/object.go#L201

Data: base64.StdEncoding.EncodeToString(object.Data()),

and piped ipfs object get | ipfs object put --datafieldenc base64 and no error

[hackergrrl]

I didn't dig into this in detail, but my spider-sense made me think ipfs/kubo#1582 might be relevant -- especially if base64 encoding does work but json doesn't.

[nycoliver]

Shouldn't this be moved to go-ipfs issues?

[daviddias]

@nycoliver agreed, looks like it is tracked on ipfs/kubo#1582, closing this one