I am interested in manipulating the “ipfs files” “root” CID. Where is it?. I haven’t found any reference in “.ipfs/config”.
I want to be able to change the “root” CID to point to an arbitrary IPFS tree and being able to manipulate it (copy on write, of course) using regular “ipfs files”.
Would be nice to understand the interaction between “ipfs files” and pinned files.
Case at point:
If I mount “ipns” with “ipfs mount”, I can do “cd /ipns/local” and then WRITE there!!!. Cool although behaviour is erratic and not entirely trustworthy. Of course, modifying content there creates new CIDs, and it is quite a challenge to learn about them. Eventually I discovered that “ipfs resolve /ipns/MY_NODE” would learn about the new “root”, but “ipfs files” didn’t change.
The FUSE API functions redefined in the IPFS require CID as an argument. Thus you can not actually interact with “root directory” because there are no IPFS virtual directories associated with the given peer ID by default, it is just an entry point of the network. Instead of this, you should provide CID as an argument for FUSE to access the “directory” inside IPFS. In this case, the only way to set “root” ID is to create a directory to share its CID as root. I have done this on my machine linking the IPFS mountpoint with directory placed on the desktop with CID integrated into the link:
ipfs files mkdir /media
CID=`ipfs files stat /media --hash`
ln -s /mnt/ipfs/${CID} /home/user/Desktop/IPFS\ Media
Do “cd /ipns/local/”. Then create content there. After a while, do “ipfs resolve /ipns/YOURNODEID”. The resolved CID will not be the same than “ipfs files stat /”. They DESYNC!!!
@jcea when you create the new content inside IPNS, the corresponding CID changes because the new nodes added to DAG. This is natural. The IPNS ID does not change because it is snapped to another entity, no?
In addition, with ipfs files stat / I got the same CIDs after and before creating 1MiB test file inside the mountpoint /ipns/<PID> which is actually a linked origin for /ipns/local: