In proc nodes can not be spawned on top of existing repos

[JonKrone]

In-process js-ipfs instances are not aware of whether or not they have spawned on top of an existing repo. This basically breaks the node as it can neither .start or .init.

I believe this is the cause of an error mentioned in a TODO here:

js-ipfsd-ctl/test/spawn-options.spec.js

Line 121 in 151303c

// `Error: Not able to start from state: uninitalized`

I think a fix for this can largely mirror how a js-ipfs instance works if the repo exists.

Another in-proc node issue that might be good to group with this: #208

[linonetwo]

+1 . I was wondering how ipfs-desktop achieve this . https://github.com/ipfs-shipyard/ipfs-desktop/blob/master/src/index.js#L238.

I copy the code but I errors, then I found out, I'm using DaemonFactory.create({ type: 'proc', exec: require('ipfs'), port }) but ipfs-desktop is just using DaemonFactory.create() .

[linonetwo]

related? ipfs/js-ipfs#1245

[JonKrone]

@linonetwo

I was wondering how ipfs-desktop achieve this

Yeah, ipfs-desktop is not using a proc node but there is a fix in #212 (here) that should allow ipfs-desktop to skip that check and rely on the initialized property of the node they spawn.

related? ipfs/js-ipfs#1245

I don't think that it is. They both have to do with initialization but I think that they're separate. This particular issue is with js-ipfsd-ctl and that issue isn't spawning any daemons.

[dryajov]

@JonKrone is this still an issue?

[linonetwo]

@dryajov Seems fixed, I'm using ipfs 0.28.2 and ipfsd-ctl 0.31.0. @JonKrone I think this can be closed.

[linonetwo]

So now we can copy the huge repo to a flash drive, and init on it at another country.