cli block get accidently mutates binary data

[kumavis]

seems ipfs block get is mutating the data a bit https://gist.github.com/kumavis/e454a7ea2e9b9520e66bc5ef3e739744
notice the last two bytes

[daviddias]

Did you manage it is on block get or block put? You should be able to cat the block after block put directly from the repo.

[kumavis]

pulling over bitswap

[kumavis]

block is stored in parity's db, so block put actually never happens
hitting the bridge's api directly works
ipfs block get gives consistently incorrect data -- my guess is that its a side effect of logging to stdout

[kumavis]

yup

 ✘ ⚙  user@work  ~/dev/metamask-mesh   master ±
 ⧖  node -e "console.log('\u0000')" | hexdump
0000000 0a00                                   
0000002

 ⚙  user@work  ~/dev/metamask-mesh   master ±
 ⧖  node -v
v8.1.0

[kumavis]

compare to

 ⚙  user@work  ~/dev/metamask-mesh   master ±
 ⧖  node -e "process.stdout.write('\u0000')" | hexdump
0000000 0000                                   
0000001

[daviddias]

We probably shouldn't be writing that \n - https://github.com/ipfs/js-ipfs/blob/master/src/cli/commands/block/get.js#L20-L21

That is why you see a difference between console.log and process.stdout.write, the first always writes a new line char

[kumavis]

ah interesting, not what i was expecting

 ⚙  user@work  ~/dev/metamask   origin-header 
 ⧖  node -e "process.stdout.write('\u0000'),process.stdout.write('\n')" | hexdump
0000000 0a00                                   
0000002

[kumavis]

if we like the newline, we could always check if the process isTTY or not, and only append the newline if it is

[daviddias]

Let's continue to track this at #900.