echo "blah" > /ipns/local/blah.txt

[glowkeeper]

I'm not understanding FUSE and/or ipfs.

If I do this: echo "blah" > /ipns/local/blah.txt, why can't I see the file when I load http://localhost:5001/ipfs/QmU3o9bvfenhTKhxUakbYrLDnZU7HezAVxPM6Ehjw9Xjqy/#/files?_k=xcgjgk?

Additionally, after running ipfs daemon && ipfs mount (or ipfs daemon --mount), why can't I see nodes I have added to ipfs under /ipfs/QmU8eXynTUJTXYPPmTvPtJbde6EbVh5EGXjSu1PR5Rsnc2, i.e. after I run ipfs add helloWorld.txt, why can't I see helloWorld.txt in /ipns/local or /ipfs/QmU8eXynTUJTXYPPmTvPtJbde6EbVh5EGXjSu1PR5Rsnc2?

Forgive me if I'm misunderstanding something fundamental, or if my question is silly, but I presumed FUSE would allow me to treat ipfs nodes as a 'normal filesystem'. However, that doesn't appear to be so (or, more likely, I'm doing something wrong)....

[glowkeeper]

After watching the IPFS demo video (https://www.youtube.com/watch?v=8CMxDNuuAiQ), I think I should be able to see helloWorld.txt under /ipfs/QmU8eXynTUJTXYPPmTvPtJbde6EbVh5EGXjSu1PR5Rsnc2. Some'ing must've gone wrong :( I'm running Ubuntu 16:04, ipfs version 0.4.6 and fuse 2.9.4-1ubuntu3.1.

[victorb]

Hi @glowkeeper! Just a word of caution, our FUSE support is lacking a bit of love and tends to be unstable. Anyways.

With the FUSE support, you won't be able to change /ipfs/-hashes, since they are immutable and change when the content change. So it would be incorrect to try to add files to /ipfs/QmU8eXynTUJTXYPPmTvPtJbde6EbVh5EGXjSu1PR5Rsnc2, since adding files would change the value.

When you're adding anything to /ipns/local, that content will be published under your peer ID, not under any existing hash. You can find your peer id by doing ipfs id and look at the output. Then you can access that content under http://localhost:8080/ipns/:your-peer-id.

There is also a bit more information about FUSE here: #188

[glowkeeper]

Thanks @victorbjelkholm! Okay, yeah - I get the immutability bit. Does that mean that once I add a file to ipfs, i.e. ipfs add helloWorld.tx, the hash generated (in this case, QmfM2r8seH2GiRaC4esTjeraXEachRt8ZsSeGaWTPLyMoG) is permanent? In other words, that hash will always contain the same thing?

[glowkeeper]

Okay, so now I can see http://localhost:8080/ipns/QmU8eXynTUJTXYPPmTvPtJbde6EbVh5EGXjSu1PR5Rsnc2/blah.txt. But why can't I see that same file under ipfs, and why I can't I see the contents of ipfs under http://localhost:8080/ipns/QmU8eXynTUJTXYPPmTvPtJbde6EbVh5EGXjSu1PR5Rsnc2? Me no understand :(

[victorb]

Does that mean that once I add a file to ipfs, i.e. ipfs add helloWorld.tx, the hash generated (in this case, QmfM2r8seH2GiRaC4esTjeraXEachRt8ZsSeGaWTPLyMoG) is permanent? In other words, that hash will always contain the same thing?

Yes, that is correct. If you have two files with the same content, they'll get the same hash, no matter where/when you add them.

Unsure of what you mean with the second comment. IPNS is simply a mutable pointer to a IPFS hash. So when you add a file, you get a hash that looks like /ipfs/Qm... which you can then tell /ipns/:your-peer-id to point to. So you wouldn't update /ipfs/Qm..., you would simply add all of your new contents, get a new hash back and point /ipns/your-peer-id to that hash.

Maybe this little demonstration would help a bit:

$ echo "Hello @glowkeeper" | ipfs add -q
QmUwv8HhzNbsPreyUtK6Se4PnfTtSWiBdWdPhRMfRmsUAC

$ ipfs name publish QmUwv8HhzNbsPreyUtK6Se4PnfTtSWiBdWdPhRMfRmsUAC
Published to QmbnQNC8fRCYcfrAonNkxfbVE7MKke7Awzi96V8u8ERS7C: /ipfs/QmUwv8HhzNbsPreyUtK6Se4PnfTtSWiBdWdPhRMfRmsUAC

$ ipfs name resolve /ipns/QmbnQNC8fRCYcfrAonNkxfbVE7MKke7Awzi96V8u8ERS7C
/ipfs/QmUwv8HhzNbsPreyUtK6Se4PnfTtSWiBdWdPhRMfRmsUAC

$ ipfs cat /ipfs/QmUwv8HhzNbsPreyUtK6Se4PnfTtSWiBdWdPhRMfRmsUAC         
Hello @glowkeeper

$ echo "Hello @glowkeeper but this time updated" | ipfs add -q
QmNVeYuStLYDoTsGNYAHLEzeMDHPG4RkHDpYij3ATgfaiL

$ ipfs name publish QmNVeYuStLYDoTsGNYAHLEzeMDHPG4RkHDpYij3ATgfaiL
Published to QmbnQNC8fRCYcfrAonNkxfbVE7MKke7Awzi96V8u8ERS7C: /ipfs/QmNVeYuStLYDoTsGNYAHLEzeMDHPG4RkHDpYij3ATgfaiL

$ ipfs cat /ipns/QmbnQNC8fRCYcfrAonNkxfbVE7MKke7Awzi96V8u8ERS7C   
Hello @glowkeeper but this time updated

What I'm doing here is the following:

• Add a file to IPFS
• Publish the response hash to IPNS under my peer ID
• Resolve IPNS address to a IPFS hash
• Cat the content from that IPFS hash
• Create a new file with new contents
• Publish this new hash to IPNS again
• Do the resolve and cat in one step, by using the /ipns/ prefix

IPFS hashes would change, every time the content change, while the IPNS record is mutable, and points to those hashes.

[glowkeeper]

That's a great explanation - thanks!

Two small issues - when I first ran ipfs name publish, I got: Error: You cannot manually publish while IPNS is mounted.

So, I did what I was told (like a good boy), and unmounted /ipns and /ipfs. Then ipfs publish, and all worked okay.

But once I'd followed your whole tutorial, and run ipfs daemon --mount, shouldn't I be able to see the nodes I'd added under /ipfs and/or /ipns? The ipfs video tutorial suggests that should be the case, but I can't :(

[glowkeeper]

Anyway - FUSE is really not the point here, is it. I mean, it'd be nice if I could see all the stuff I added as a regular filesystem file, but as long as I can see things under ipfs and ipns themselves, I'm not certain I'm that bothered about FUSE, really ;)

[victorb]

Yeah, but as I said, our FUSE support is flaky, to say the least.

But I tried the following and it worked for me: (first start daemon with ipfs daemon --mount after creating the mount points)

$echo "hello WOOOOOOOORLD" | ipfs add -q
QmdHom8wF6vcMSdWjpFkxCoGcJYPDnKo5qDn3wWn8LGhgN

$ cat /ipfs/QmdHom8wF6vcMSdWjpFkxCoGcJYPDnKo5qDn3wWn8LGhgN
hello WOOOOOOOORLD

[glowkeeper]

Hmmmm - well, I could do that too. So it seems everything is working as intended and the failing was my brain (as usual). However, I think the 'problem' is to do with directory mount point permissions or something, 'cause when I do this cd /ipfs && ls, I get: ls: reading directory '.': Operation not permitted. What's more, find /ipfs just returns /ipfs. However, cd /ipfs && cat QmdHom8wF6vcMSdWjpFkxCoGcJYPDnKo5qDn3wWn8LGhgN returns hello WOOOOOOOORLD, as expected. So the file's there, it's just kinda hidden. Or it's magic. Or something.

So, as a test, I did this:

$ mkdir /tmp/blah && cd /tmp/blah`
$ for file in 1 2 3 4 5 6 7 8 9 10
> do
> echo $file > $file
> done
$ ipfs add -r .
added QmdytmR4wULMd3SLo6ePF4s3WcRHWcpnJZ7bHhoj3QB13v blah/1
added QmUnKvaCFaE8DSHMAq2XeHfrz1wW62uVbb4dNtxQ5zXy6n blah/10
added QmSFxnK675wQ9Kc1uqWKyJUaNxvSc2BP5DbXCD3x93oq61 blah/2
added QmdQEnYhrhgFKPCq5eKc7xb1k7rKyb3fGMitUPKvFAscVK blah/3
added QmR56UJmAaZLXLdTT1ALrE9vVqV8soUEekm9BMd4FnuYqV blah/4
added QmZa1tLVa8iEoDWbvwxV7rCxGnVGUff2jhF7a2DyCk5SbY blah/5
added QmQXqZdEwXnWgKpfJmUVaACuVar9R7vpBxtZgddQMTa2UN blah/6
added QmaHbbushv2gYBUyofdm853cy1HTcNuinqagCfMjMdGmNw blah/7
added QmYvu7a4kcf1drqHfZNDdoyVbPHnS3LmDsao9YrAVBmfjP blah/8
added QmSRQJmXLc6xBHHfrFu2CmtJa9ep4wRwhy7oky8tH4P74J blah/9
added QmQmXQPeWdtKLMHYFdcjZY6GBH18ZHGSpyPmVEZ6zg8f9U blah
$  cd /ipfs/QmQmXQPeWdtKLMHYFdcjZY6GBH18ZHGSpyPmVEZ6zg8f9U && ls
1  10  2  3  4  5  6  7  8  9
$ cat 4 
4

In other words, all works correctly. I think the moral of the story is add everything under a directory (i.e. ipfs add -r /some/place, and then you'll be able to cd /ipfs/[rootDirectoryHash] and FUSE will behave as you'd expect. Right?

[flyingzumwalt]

This issue was moved to https://discuss.ipfs.io/t/echo-blah-ipns-local-blah-txt/270