Different file hash on ipfs add


Since day i am trying to disocver why my file is not accessable using public gateway, only through my gateway.

I have a 1000s of files added to ipfs netwrok through bash script using the floowing code:
/usr/local/bin/ipfs add -w -Q --nocopy $filename
the i store the result on database using the returning result from the above code.
All the code return using the reqular IPFS pattern that starting with Qm… hash.

When i finished uploading all file and tryed to access those files from public gateway, the files in not downloadable.

I check files using the following IPFS command:
ipfs dht findprovs $filehash
My IPFS node is not exisit within the list of node.

Then i start verify the files on filestore using
ipfs filestore verify
The files is there and they are oK. But all file hash start zb2rhY… hash.
I knew that the hash given by the bash script that start with Qm is for directory because i appand every file in it own directory
/usr/local/bin/ipfs add -w -Q --nocopy $filename
But the above command mean i can access the file by using
but they are not accessable, while i can access it using :
Then i try to chech the resolver to find which hash the network give me for that file:
the reult give my the hash start with Qm… which is not accessable .

I try today adding file from shell not from bash script .
And every thing seem OK. and the file added OK.
What wrong with those that added by bash script?

What is the output from ipfs config Reprovider.Strategy?

What happens if you try to access it through your local gateway? For example, http://localhost:8080/ipfs/$hash/$filename (assuming you’re using the default gateway port, 8080)

Hashes beginning by “zb”, huh?
Reminds me of the ongoing effort to switch multihashes from base 58btc encoding to base 32 encoding: https://github.com/ipfs/go-ipfs/issues/6220 , https://github.com/ipfs/ipfs/issues/337

I’m not able to point you to a particular repo, but IPFS is switching to base 32 across the stack, and Qm… will soon be legacy and you will see zb… everywhere. They are working hard not to introduce breaking change, but I guess it’s hard.

Maybe try to encode base 32 <-> base 58btc in your script?