guarantee mutually exclusive access to persisted state

[btc]

As part of its normal operation, IPFS persists these items to disk:

• logs in IPFS_DIR/logs/
• a configuration file as IPFS_DIR/config
• a leveldb datastore in IPFS_DIR/datastore/

Collectively, we refer to these as the repo.

issue
We wish to ensure that access to these resources is granted to just one process at a time.

While different mechanisms could be used to enforce mutually-exclusive access for each of the three resources, it may be simpler to provide a common mechanism to cover them all.

proposal
A good first step is to repurpose the daemon.Lock (lock file) as a repo.Lock or a resource.Lock.

NB: This doesn't provide guarantees against callers who sidestep the Lock and go after the resources directly.

[jbenet]

Collectively, we refer to these as the repo.

Yeah we have been using this. do we want to continue? is there a better word?

The proposal SGTM. 👍

[btc]

Repo SGTM

[dborzov]

@maybebtc , 👍 good points here.

It seems that currently @jbenet is locking a token file IPFS_DIR/config/deamon.lock as a flag that the repo is "loaded" and in use: https://github.com/jbenet/go-ipfs/blob/91fe0d953408c6d7656ac02b17f65f110780cb31/core/daemon/daemon.go#L15 .

Are you suggesting locking everything within IPFS-DIR altogether? Or is it about moving it from the deamon to initialization check for every running instance?

BTW, evidently using deamon.lock as the flag token file is the fallback behaviour for non-Unix systems for github.com/camlistore/lock already :)

[btc]

Are you suggesting locking everything within IPFS-DIR altogether? Or is it about moving it from the deamon to initialization check for every running instance?

using one mechanism to manage all items in IPFS_DIR

[jbenet]

@briantigerchow i believe this can be closed now? reopen if not.