ipfs name publish does not work while /ipns is mounted.

[Crest]

The ipfs name publish accepts and silently ignores requests to publish names while /ipns is mounted.

[cryptix]

@whyrusleeping can explain the gory details for this but we should return a proper error like "I can't let you do that while fuse is mounted" until this is resolved fully.

[jbenet]

👍

[whyrusleeping]

I can fix this pretty easily after what i learned implementing save

[whyrusleeping]

well, okay, maybe not pretty easily, but a solution is possible. The problem i'm running into right now is that /ipns expects the published entry to be an ipfs object reference, where we recently changed things so that we can publish paths as part of our ipfs entry. Im not sure what the best logic for making that distinction is.

[cryptix]

related issue: #964

[wking]

On Thu, Jun 04, 2015 at 09:42:22AM -0700, Jeromy Johnson wrote 1, #1187:

Imagine the fuse mountpoint is mounted, and two different programs
are editing different files at different places in the tree. using
the patch command, if one of those writes to the dag, it breaks the
entire tree that the other one is on. This command goes through the
ipnsfs interface and is threadsafe, and wont break the fuse
interface.

I'm trying to put a finger on what's different, and it seems like the
difference is that ‘ipfs object patch …’ uses AddNodeLinkClean
[2,3,4,5], while #1187 uses some additional locking in AddChild 6.
‘ipfs name publish …’ should just be about writing the record, so I'm
not sure how the FUSE daemon gets informed of the change (maybe it
polls? See also 7). Do we just need better locking in the “respond
to an updated IPNS-link” handler?

[whyrusleeping]

no. the difference is that the save command uses the ipnsfs interface.

[wking]

On Thu, Jun 04, 2015 at 10:32:03AM -0700, Jeromy Johnson wrote:

no. the difference is that the save command uses the ipnsfs interface.

Why is the FUSE daemon's “respond to an updated IPNS-link” handler not
using the ipnsfs interface?

[whyrusleeping]

i'm not sure i understand the question you are asking. what do you mean by 'the FUSE daemon's “respond to an updated IPNS-link” handler'?

[wking]

On Thu, Jun 04, 2015 at 11:51:42AM -0700, Jeromy Johnson wrote:

i'm not sure i understand the question you are asking. what do you
mean by 'the FUSE daemon's “respond to an updated IPNS-link”
handler'?

Here's the situation I think @dylanPowers was calling out 1:

1. The FUSE daemon is is serving /ipns/…
2. Somebody updates an IPNS record (could be the record for the local
   IPFS node via ‘ipfs name publish …’, or could be some other node,
   or could be a sycalls writing under /ipns/local/…).
3. The FUSE daemon notices (2), and adjusts the served filesystem
   appropriately.

so whatever logic the FUSE daemon is using for (3) should be general
enough to handle IPNS-link updates from any of the sources listed in
(2). I was trying to figure out how this was handled now by looking
through ipnsfs/ and fuse/ipns/ earlier today, but couldn't locate the
the code that actually loaded the new IPNS-linked-root after a publish
call (e.g. in 2), but couldn't find it. Maybe the current IPNS/FUSE
implementation relies on mutating the in-memory version of the loaded
nodes during the syscalls writing under /ipns/local/… and doesn't have
a separate “respond to the updated IPNS-link” logic? If so, I think
that's the problem we need to fix.

[whyrusleeping]

TODO: ipfs name publish should fail with friendly message if fuse is mounted

[hackergrrl]

Done: https://github.com/ipfs/go-ipfs/pull/2323/files#diff-5ee6d6df05b05dae1b72d8f5289f63f3R78