zimoun schreef op vr 27-05-2022 om 18:19 [+0200]:
> I miss why such lengthy discussion about these theoretical
> failures of last-expiry-cleanup when it is also true each time 'read'
> is used, see least-authority or ui.scm etc.

(guix ui) cannot do anything about corruption except report the read
failure, whereas (guix cache) has a very strict file format so it is
feasible to detect whether it's corruption or just the user making a
typo (because those files aren't directly written by a user) and
additionally it can very easily handle the corruption.

For (guix authority), there is already a corruption detection mechanism
("guix gc --verify=contents") -- there even already is a repair
mechanism: "guix gc --verify=contents,repair".

> It is not resistance but pragmatic: the only case of interest is
> the empty file, which happens -- all the others, I am still waiting
> at least one bug report about them i.e., a user runs "guix time-
> machine" and suddenly the file last-expiry-cleanup is corrupted and
> "guix time-machine" unusable.

* The general issue of file system corruption in Guix is already known
  (the Guix daemon never calls fsync or sync except on the SQLite
  database), though I don't know if a formal bug report exists about
  that.  There have been many bug reports on individual cases though.
* This bug report already exists: <http://issues.guix.gnu.org/55638>.
  (You say the file system is not corrupted, but how would you know?
  Even if not, the symptoms are almost identical.)
* I do not see the point of waiting for any known suffering users
  reporting the bug before fixing the bug.  Seems negligent to me
  if the fix is easy and known, and not very pragmatic for those
  future (or maybe current and shy) users.  Also has a risk of rebase
  conflicts, which does not seem pragmatic to me.

Greetings,
Maxime