search

elves / elvish

Powerful scripting language & versatile interactive shell
https://elv.sh/
BSD 2-Clause "Simplified" License
5.62k stars 300 forks source link

Report about corrupted database #596

Open unkaktus opened 6 years ago

unkaktus commented 6 years ago

Due to power loss my elvish boltdb got corrupted, so elvish panics with:

panic: pgid (51539607602) above high water mark (1413)

goroutine 1 [running]:
github.com/elves/elvish/vendor/github.com/boltdb/bolt.(*node).spill(0xc42007ea80, 0xc42011d770, 0x6)
        /go/src/github.com/elves/elvish/vendor/github.com/boltdb/bolt/node.go:375 +0x715

It would be definitely great to display some error message like corrupted database.

xiaq commented 6 years ago

Sorry about your corrupted Elvish db... The panic sounds like a Bolt bug though; here is a similar one.

unkaktus commented 6 years ago

@xiaq, is it a good idea to back up the database at some point? Of course it would be nice not to have this kind of bug at all but still... :wink:

hanche commented 5 years ago

Just for the record, this happened to me today. Discussed on chat. I had the db on an nfs mounted home directory, and carelessly (?) worked on several machines with the same home directory simultaneously. Boom, corrupted db file.

krader1961 commented 4 years ago

FYI, boltdb is not network filesystem safe. See https://github.com/boltdb/bolt/issues/690. I don't see any issues in the bbolt fork elvish uses that mention NFS or other shared file systems. So it seems reasonable to conclude that the boltdb used by elvish is still not safe to use when the home directory is on NFS (or other shared file systems such as Dropbox). This is another good reason to move the elvish interactive database out of ~/.elvish as proposed by the XDG Base Specification issue.

krader1961 commented 3 years ago

FWIW, I got tired of Dropbox creating "conflicted copy" versions of my ~/.elvish/db file.

I am surprised this invalid sharing of a mmap'd file, treated as a key:value store, hasn't caused me to notice history corruption. It appears to be a fortuitous intersection of Elvish, UNIX and Dropbox file semantics.

So I ran

> mkdir ~/.local/share/elvish
> cd ~/.elvish
> ln -s ~/.local/share/elvish/db db

That example is obviously incomplete, and unique to my situation, but illustrates how some Elvish users might deal with this issue. It would be nice if Elvish defaulted to storing its interactive command history in a file in a directory unrelated to its config files.