@bluelovers I can’t get access to
QmdvbTgdaoqYV2rmh6raYT5pWZ7Lujhz73M6xtaRcC5xXn to see what it looks like. However, the hashes will be different if the names of the files are different. I can’t see the full name of the php file, but if it ends with some different characters that will change the hash.
Edit: @bluelovers I took a look at those objects and the difference is that the “size” field reported for each of those two blocks is different.
For UnixFS (which is the format you’re currently working with): In order to help with programs that want to estimate “how big” a given file/directory is without actually downloading it the parent directory contains a reference to the size of the file referenced by CID. For some reason it appears that your files are being reported as having different sizes.
- hof.zip : size 20010278
- php… : size 23016923
- hof.zip : size 20015062
- php… : size 23022389
How did you create these UnixFS objects?
need use ipfs desktop or something else
i don’t know why ipfs.io can access, but ipld.io can’t
full name is same
one is by ipfs desktop
one is by https://share.ipfs.io
file is same file in local pc
Thanks. It looks like for some reason go-ipfs and share determine the files to be different sizes.
Both sets of files show exactly the same size on my end.
cmpshows zero differences in binary content.
cksumshows no difference in content.
However, the files listed under
QmbHK4rKG1p87DTnemXrhh9QSxZk6xBCSHg5E985MEH1Zu seem to be missing their last modified date information. It’s set to the start of UNIX Epoch.
As a test, I created 2 simple text files, copied them, modified the “last modified” date to the start of Epoch and added both sets of directories. However, I got back the same CIDS for each set.
So, I can’t duplicate your problem. And I don’t seem to have the same problem as @
I’m using V 0.6.0