repo fsck doesn't remove badger lockfile

[djdv]

Version information:

go-ipfs version: 0.4.12-dev-e7acb96c6
Repo version: 6
System version: amd64/windows
Golang version: go1.9.1

Type:

Bug

Severity:

Medium

Description:

Running ipfs repo fsck reports that lockfiles were successfully removed but they're not.

[kevina]

From ipfs-dev channel on irc:

<kevina> stebalien: if your around, why was I assigned to #4301?
<stebalien> kevina: I probably fat fingered something. I intended to assign that to Magik6k.

[schomatis]

@djdv Thanks for reporting this. It's a Badger error currently being fixed (see dgraph-io/badger#424), in short, the Windows lock implementation needs to create the file, if LOCK already exists Badger (incorrectly) assumes another process is using the DB (and doesn't take into consideration the scenario where Badger unexpectedly stopped and didn't clean up the lock). In Unix Badger just (correctly) tries to acquire a lock over the LOCK file (not caring if it already exists or not, just that it's not being used by another process).

The ipfs repo fsck command clears the LOCK file from the datastore directory (which I'm not sure what it does), it's not in charge of cleaning Badger's internal lock (in the badgerds directory).

I'll keep an eye on the Badger fix.

[Kubuxu]

@schomatis the LOCK file in a datastore is to prevent multiple instances running over the same repo. The ipfs repo fsck removes the LOCK file from it because we had the same issue badger has currently. We didn't have proper locking on Windows and were using just a file to do it. Currently, we lock properly on Windows so ipfs repo fsck isn't really needed anymore.