disable 'ipfs name publish' while /ipns is mounted

[whyrusleeping]

One current issue with the /ipns mount is that if you do an ipfs name publish QmXyz while its mounted, it wont know to update. I propose that while /ipns is mounted, we disable the publish command. Not doing so causes a bunch of weird issues, such as "What do we do if the users current working directory is in /ipns and we change the entry?"

[jbenet]

I propose that while /ipns is mounted, we disable the publish command.

👍 SGTM. pls make sure error msg to user explains why

[dylanPowers]

What will the alternative be? What do I do if I have an ipfs hash that I want to publish to ipns?
Also what happens when you're in the ipns directory of some other peer and they update their ipns entry?

[whyrusleeping]

@noffle is this done?

[hackergrrl]

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

[NiKiZe]

Now we get "Error: cannot manually publish while IPNS is mounted" (which does not show up much on google)
So what is the appropriate workaround for publishing a hash while IPNS is mounted?
And what could be done to have ipfs name publish implement that workaround internally?

[ntninja]

Can we get an update on this?

[Stebalien]

@schomatis has been working on MFS and @djdv has been working on FUSE (in a different branch). Those efforts won't fix this but they should bring us closer.

[martinhbramwell]

Does this mean there currently exists no way to publish an IPFS directory to IPNS?

I'm a complete newb here, reading articles like The definitive guide to publishing content on the decentralized web, so I do not know where to look for work around solutions.

[Stebalien]

You can publish a directory. You need to:

1. Add the directory using ipfs add -r DIR.
2. Publish the directory using ipfs name publish /ipfs/OUTPUT_OF_LAST_COMMAND.

[ldeffenb]

You can publish a directory. You need to:

1. Add the directory using ipfs add -r DIR.
2. Publish the directory using ipfs name publish /ipfs/OUTPUT_OF_LAST_COMMAND.

But (2) fails with "Error: cannot manually publish while IPNS is mounted" if you're running with /ipns mounted. So, I guess we need to stop the daemon and restart it unmounted, publish the name, and stop/restart the daemon with mounted?

[Stebalien]

Yes.

[benaryorg]

So, I guess we need to stop the daemon and restart it unmounted, publish the name, and stop/restart the daemon with mounted?

That is hardly a solution to any problem.
On UNIX and UNIX-like systems you always had the problem of directories possibly changing while having them open in some form since they are mutable.
Be it because your directory is moved elsewhere while it is your shell's cwd, or a file being deleted or moved while the file-handle is still open (also applies to directories actually).
Symlinks may change at any time too even if you've opened a file or directory using that symlink as a path element, but you will still have the same file open regardless.

There are two issues right now, one is that having to stop the daemon or unmount a filesystem to publish a record is not a viable solution, so please allow us to do that, we're fairly capable of taking care of our file handles, it's okay to warn, but there ultimately must be an override.

Secondly you've raised the issue of what could possibly happen if we were to screw up, however for that we need some more in-depth information.
When I open a file in /ipns/ and keep the handle open while anything changes in the namespace, even if I have the handle open for half a year, will my handle still refer to the same /ipfs/ hash it did originally (important: I am talking about an open handle/fd here, not reopening the same filename again)?
If not, will the descriptor break on use (failing read(), eof flags being set,.…), or will we encounter inconsistent data on chunk boundaries (i.e. read the open chunk until the end and then read the corresponding next chunk of the newest file) or at cursor position (next read() yields data from current /ipns/ resolved file)?

[bqv]

So, I guess we need to stop the daemon and restart it unmounted, publish the name, and stop/restart the daemon with mounted?

That is hardly a solution to any problem.

Agreed, that is genuinely a ridiculous state of affairs.

[djdv]

Agreed, that is genuinely a ridiculous state of affairs.

Agreed, a file system that can't practically be mounted in the first place, combined with forcing the user to offline the mount to do basic tasks - is bad.
For what it's worth, this was one of my responsibilities to fix, but I failed to do so.
I'm still trying to coordinate with the maintainer about it, but this particular problem will likely be one of the last (mount) issue we end up solving properly.

I've previously had branches which do what @benaryorg is describing. Both locking in a reference at the time it's opened (resolve ipns->ipfs and retain this hash) as well as a later implementation which resolve as late as possible instead (during Read(), etc.).
Both can work fine, with the latter making the most sense for a mutable file system (imo), but the actual issue is coordinating locks between services. (In particular, between the "name", "key", and "mount" interfaces)

Locking is done now, but in a simple all-or-nothing style. If the mount is active, all keys can no longer be published, whether they're being accessed or not.

I've mentioned in discussion that we can most likely come up with some kind of resource locking API that resides on the node and allows node services (like name or mount) to acquire finer grained resource locks.(e.g. node.Lock("/key/Qm..." or whatever)
Allowing the actual mount implementation to take advantage of it and lock out specific keys dynamically. As in, not just when they are mounted, but when nodes underneath the mount are actually in use (checked/acquired during Open, etc.).
Edit: this would apply to, and be usable by, other file system APIs as well, for example the relation between mounting MFS and the ipfs files commands would likely do the same thing with a symbolic reference / name (lock("/files"))

That said, there are some more fundamental problems to fix first. I don't think it's even worth enabling people to use the IPNS mount feature with the performance being in the state its in.
Ideally, we'll fix both of these problems and more, but in priority order.
I'd like to help make something that works on the currently supported platforms, is actually usable with repos above 300MB, and is more dynamic in a lot of little ways (,dynamic locking being one of them).
The former 2 seem doable and have prototypes, with the latter hopefully coming later.

As always, anyone is free to reach out to me about this. I can keep you posted as progress is made on it, and hear criticisms etc.

[djdv]

For what it's worth I hacked together a workaround in this (very unstable) branch: https://www.youtube.com/watch?v=24N-qNplHk0

If you only mount IPFS but wish to publish, you could use this branch to mount IPFS alone, and have no conflicts with ipfs name.
If you mount both IPFS and IPNS, I added a way to take just the IPNS mountpoint down without taking the entire node down.
The UI/UX around it is annoying right now but it's just for demonstration. With progress this should be more or less transparent, with the goal being to allow publishing even while the mountpoint is active, so long as no handles under the key you're trying to publish to, are themselves open.

I think it's doable, but depends on decoupling the existing fuse interface implementation (more).
The alternative approach is to replace that interface (which is currently in progress), since the existing implementation has other issues itself. But the new implementation will need to be well tested if it wants to replace the existing one.

[bqv]

I noticed I can just umount /ipns seemingly without consequence, so I've just been doing that, and ipfs mount if/when I need it back

[djdv]

That's effectively what's happening in that patch.
It should be noted that the opposite will cause issues in the current implementation, since IPNS mountpoints link into the IPFS one.

I think we could automate the re-mount (with a prompt) in ipfs name publish, and make it a little nicer for the user.
It'd be better than taking the whole node down but still a disruptive workaround if you have open IPNS files.

The interface I'm trying to replace has IPFS and IPNS as independent interfaces, which should make remounting the instance simpler.
But I also think it should be doable to not require the unmounting at all (even automatically) if we can avoid it.
By basically just asking the file system interface if that specific key has any open handles or not. (Or through whatever lock interface we may put on the node)

For what it's worth, I'm going to keep working on this when I can since it's something I'd like to see improve. I think these interfaces are kind of important for something with "FS" in its name.

[timebankspace]

first,
"umount /ipns"

then,
ipfs name publish
it works!

later,
"ipfs mount"
IPFS mounted at:/ipfs
IPNS mounted at:/ipns

[bqv]

We know. That's the problem. 😐