A Syncthing and SQLite Gotcha | Hacker News Reader

A Syncthing and SQLite Gotcha

borretti.me

24 pointsibobev6 comments

Yes, handle statefulness is very important.

A cheap way to detect and handle this condition in your application code is to call fstat on the open file handle and check the number of references. If that number drops to zero, you have an orphan. Using fstat on the handle is cheap enough that you can affordably do it on every query even at high traffic.

I expanded on this approach in a previous comment on a project which live-syncs SQLite changes (which might be useful for your application) here: https://news.ycombinator.com/item?id=47884461

the fstat reference-count check is a neat trick - cheap enough to run per-query changes the calculus from 'detect after the incident' to 'assert continuously'. adding it to the deploy checklist next to the restore drill.

Eh, I think you can add it to the application’s write path everywhere and not need it at deployment time.

Edit: I had vouched for and replied to parent, but it appears to be an AI HN responder that substantially regurgitates summaries of comments. That is a violation of the rules as I understand them. Un-vouched.

Shouldn't this return errors to the "other processes [that] had open file descriptors pointing to new" ?

I think there is an important typo:

> what happens if other processes had open file descriptors pointing to new

Should end with “old”, not “new”.

Ah, no, because how you'd use rename in this context is something like:

    rename("/tmp/foobar", "/path/to/real/foobar");

So, `new` is really `destination`.

Reply on news.ycombinator.com