Leveldb/storage: corrupted or incomplete CURRENT file

I get the following error five times when I try to start the most recent version of PulseThing on Windows 8.1.

[monitor] 03:27:38 INFO: Starting syncthing
[26Y7O] 03:27:39 INFO: syncthing v0.10.1 (go1.3.3 windows-amd64 default) jenkins
@build.syncthing.net 2014-10-12 12:09:40 UTC
[26Y7O] 03:27:39 INFO: My ID: 26Y7OM6-FAI6BEQ-GOOEHNV-GXEMZJ7-5XFPLQS-TD6YGL5-I2
TKKGS-EPLKSQI
[26Y7O] 03:27:39 FATAL: Cannot open database: leveldb/storage: corrupted or inco
mplete CURRENT file - Is another copy of Syncthing already running?
[monitor] 03:27:39 INFO: Syncthing exited: exit status 1

I ran a previous version of SyncThing briefly a few months ago, and I don’t remember it having issues like this. Can I just nuke the leveldb database and start over? I don’t know where it’s stored.

Yes, you can just delete the database. It’s stored in your programs home directory, which I think is AppData directory (the more accurate path might be shown when you call --help)

Would not deleting confuse the overall synching though? I mean if there are files to be deleted on the node with the corrupt database, how would other nodes know how to go ahead? Delete or send them back to the one with corrupt database?

The reason I am asking is that I got this issue couple times, abit annoying on Android especially given that probably a new database means a full scan which means that battery usage will spike.

Yes, removing the database will confuse syncthing, in that local changes that have been detected but not synced by the rest of the cluster are forgotten. For file changes this means you will get a conflict when they sync again, for deletions it’ll have forgotten the delete so you get the old file back.

It would be interesting to know how this happens though. I’ve run basically every commit of syncthing ever, on a number of boxes, with lots of stops and restarts and crashes basically every single day, and I’ve so far never ever managed to get a corrupt database. This being common for other people is … odd.

Our users mainly experience this as they use laptops and let them die whilst sleeping

I ran into this after having to force reboot a Win8.1 machine. Running SyncThing 11.2

For other Win8 users with this issue the path to affected files C:\Users<username>\AppData\Local\Syncthing\index-v0.11.0.db

move those files to a folder & restart SyncThing, with the caveats noted above about out of sync data.

Ed

I got this again today. I am on Arm Linux on Android tablet.

I wonder if immature killing of ST binary can bea cause?

Yes, as it’s a database, hence you kill it mid-transaction, causing current file corruption.

Well, I would not know if I killed it mid way or not. It was a question. I think I used shutdown method however sometimes devices reboot, crash etc.

Agree, they do, and this is when you might have to intervene.

FYI: SQLite can handle an application crash / OS crash / power failure / whatever at any point, including during a transaction.

SQLite performs much worse with the data that we have.

Yes, but applications that require 15 minutes of investigating because your PC crashed, can be rather annoying to a user. The number of occurrences on my PC of an app not being able to run in the last 4 years = 0. Occurrences since installing syncthing 3 months ago = twice. At least from my perspective: its safe to say this is bug that to be investigated and addressed for more wide spread usage.

If it occurs even once per user over a 5 year period, its a lot of time used of the worlds population.

Try the bolt backend