Repo is opened - trivially to lock out

[theduke]

fn main() {
   zbox::RepoOpener::new().create(true).open("file://./data", "password").unwrap();
}

cargo watch -x run

Cargo watch will immediately restart due to the data directory changing.

This results in a Error::RepoOpened error on the second run, due to the repo.lock file, without the API offering a way to recover (by just deleting the lock file).

The lockfile should probably store the process id and delete itself if it doesn't match.

(of course watch should ignore the data directory in real use, but this demonstrates a problem)

[burmecia]

Keep watching on ZboxFS data folder is not good idea, you probably only need to watch source code change. For example, using below command will only watch src, tests and examples folder.

cargo watch -w src -w tests -w examples -x 'run --example zbox_demo --features storage-file -- --nocapture'

Another option is, If you're really sure what you're doing, you can break the exclusive repo access promise by using force option, which will open repo regardless lock file. But be cautious because this can potentially corrupt your repo data.

RepoOpener::new().force(true).open("file://your_repo", "pwd").unwrap();

Documentation for force option is here: https://docs.rs/zbox/0.8.7/zbox/struct.RepoOpener.html#method.force

[theduke]

You missed this line:

(of course watch should ignore the data directory in real use, but this demonstrates a problem)

I just stumbled over this before adding a --ignore flag. The point was this could occur in real live when the application crashes.

I didn't see the force option though.

I have implemented a pid lockfile , but this would be helpful to include out of the box.

[burmecia]

Sorry I missed that line.

I think there is a case when using lock file regardless it contains pid or not. For an example, process A opened a repo and it crashed with lock file undeleted, and another process B started and it sees the pid lock file is different. How process B deal with this situation? If process B forcefully delete that pid file to clear the lock, how it distinguishes the case if process A is still running?

So the trade-off is to use force option, it can open repo regardless the lock but at the cost there might be chances data get corrupted.