Update MFS root CID

Hello,

How to manually change the hash to be used as the root folder for ipfs files?

I manually corrected (using ipfs object patch rm-link) the root folder because it contained an unreadable file. This operation generated a new version of the folder with a new hash and I now want this hash to be used as the root folder of the files api (at the end ipfs files stat / should point to the new generated folder).

Any idea ?

Nicolas

You should probably not have manually corrected the object. You needed to use ipfs files rm /whatever-you-removed instead.

Thanks Hector,

I already tried but for some reason the object is broken and most of high level commands hang when trying to interact with this particular file. For example, the following commands fail:

  • ipfs files rm /file
  • ipfs files ls -l /file
  • ipfs files ls -l
  • ipfs get cid

but ipfs files ls /file works.

I still can access all other files. I still can retrieve them as long as avoid retrieving at the same time the broken file.

This is the third time in one week I had to recreate the store I’d like to be able to repair it myself. This is why I was asking my question.

I’d like to know more about this. Is there a way to reproduce the issue?

I am not 100% sure, but I think there is no way to replace the MFS root other than manually writing a program to fix the datastore entry (the datatstore path for this is /local/filesroot and that’s probably inside a leveldb in the .ipfs/datastore folder.

imho it may be worth opening a feature request for ipfs files replace-root, but it would be nicer to know why things are stopping to work in the first place.

I was used to do a lot of

cat "$FILE" | ipfs files write --create "$DIR""$FILENAME"

this command was in one of my script and I launch this script sometimes in parallel (in several terminals). I might as well cancel some of them with ctrl+c.

I tried to reproduced the same command with a file that failed but I never was able to reproduce the problem this why I start thinking that ctrl+c or maybe the concurrency might be a reason of the failure.

I could open a Issue on github for that and maybe if I keep trying I could reproduce the bug and provide the team with a buggy datastore to investigate but my problem is still the same : now how do I repair a bugged folder ?

If the bugged file is at the mfs root, I have no choice than export all the files out and recreate a whole datastore (several GB…).

If the bugged file is in a folder, I have to move all the file out of this folder (except the buggy one) and rm the folder itself.

Are you running Garbage Collections as well?

I don’t call the garbage collector collection manually if it’s what you mean.

For anyone coming around here, I wrote a small program to replace the MFS root: https://github.com/hsanjuan/mfs-replace-root

1 Like