I think we need to live with this.
GtkRecentManager is as simple (and bad) as possible in terms of storage technology. It heavily relies on glib for bookmark file (actually in-memory structure) and its serialization function. All it can do is to maintain single global recently-used.xbel on disk for all applications. When app flushes its internal bookmark view to disk, GtkRecentManager relies on glib_file_set_contents(), which does the following:
1. Create temporary recently-used.xbel.XXXXXX (with 0666 mode
, but its irrelevant since .local/share should be 0700 anyway) and fallocate() it.
2. Copy its internal serialized bookmark file into temporary and do fsync() (slow!) on it.
3. rename() recently-used.xbel.XXXXXX -> recently-used.xbel
4. Do flush() on .local/share (maybe slow).
Thats how atomicity implemented.
Of course your program can be terminated between (1) and (3), so temporary file would be left on disk forever, no one will take responsibility for it.
Its bad that we can left in such situation, esp. when fsync() is slow (such filesystem or just HDD).
But its even worse that we are writing entire bookmark file on every flush.
Also we can lose our bookmarks easily, imagine that applications A and B both want to flush their bookmarks simultaneously. 'A' state is <prev state> + foo.odt. 'B' state is <prev state> + bar.jpg.
We can end up with <prev state> + foo.odt OR <prev state> + bar.jpg easily, but we want <prev state> + foo.odt + bar.jpg.
