Version: 0.4.10
Issue at hand is that it is no longer possible to use ipfs ls with blob hashes (hashes of straight up files). It was broken somewhere along integration of sharding or cleanup of some error messages.
~ Kubuxu - this was edited by me as it is top message of the issue
Please fill out the template when creating issue, also please provide steps to reproduce.
I faced the same issue.
Steps to replicate:
ipfs init
ipfs add pictures/20160611_181116.jpg (// this is jpg image of size 2MB)
ipfs ls QmVN6qhejgEDPFunvsWQqDWRmeCNqyC7iz8XZuHM137vm2
and there you get:
Error: merkledag node was not a directory or shard
However, ipfs object links QmVN6qhejgEDPFunvsWQqDWRmeCNqyC7iz8XZuHM137vm2 works as expected and returns the links:
psingh@GSG2PD-FT0272:~$ ipfs object links QmVN6qhejgEDPFunvsWQqDWRmeCNqyC7iz8XZuHM137vm2
QmazQnDVZe8aeYNcnkjqcde4hU12ZNQ1Hs4mhRo8v4AnEe 262158
QmaN1c95LL8RpQrzcbEKPQDLoEAwhg23kCUCeufFKcuhJV 262158
QmbCQPmtTuwUAy4jxPzzaPxL9F2hHJygYeCjrhuWSdkT13 262158
QmR2VSD93DKqwJ82DbQW8yNNoLnMuivsdQbcVXavTZj1mo 262158
QmTLTET5HvMLyx46HCoCzfAYn5s3zVfMJSJiB1aTHQV8iV 262158
QmS7UgCJBehkGiDMz7NjcrkMZZwWn99UXkC4eFYhQuNNis 262158
QmeXZZZAFXeiyXdm12M9UJ5HyYZeS1rimEG1AxAVCTm83R 262158
QmV11TW1jgKixaQd76FKkbct136e1jQr4usy1f6Ve5vpYv 154117
My go version is : go version go1.8.3 linux/amd64
OS : Ubuntu 16.0
So I guess the expectation here is that ipfs ls works on straight file hashes.
I've been experiencing this same issue.
@conrad @prashantprabhakar can you confirm my above assumption?
Can you also give full output of ipfs add in this case.
~/Code/ipfs/test >>> ipfs add hello
added QmT78zSuBmuS4z925WZfrqQ1qHaJ56DQaTfyMUF7F8ff5o hello
~/Code/ipfs/test >>> ipfs ls QmT78zSuBmuS4z925WZfrqQ1qHaJ56DQaTfyMUF7F8ff5o
Error: merkledag node was not a directory or shard
I should add that this did work for me initially a week or two ago. I don't know what changed.
Everything else I do with these files so far seems to be working.
For example, I can ipfs cat the file or retrieve it by hitting http://localhost:8080/ipfs/QmT78zSuBmuS4z925WZfrqQ1qHaJ56DQaTfyMUF7F8ff5o
Ah, yeah. It seems that ls was changed to no longer work on files. Lets get this fixed (should be easy).
So the expected behavior, is what ever it was before the change. Sounds easy enough.
Git bisect determined that commit c4c665395a8ef92360f4251bbb3df712538035f6 was the cause of the regression. Working on fixing now.