bug#41710: Possibly found a bug while doing a "guix pull"

[Danny Milosavljevic <dannym@scratchpost.org>]

[-- Attachment #1: Type: text/plain, Size: 1461 bytes --]

Hi,

On Mon, 8 Jun 2020 01:15:46 +0200
Léon Lain Delysid <leon.lain.delysid@gmail.com> wrote:

>or
> if my system crashing twice during a pull command somehow broke it, 

Probably.

>but I
> hope this feedback helped. 

It sure helped.  It's good to know that that can happen.

I remember the first time I used Guix, I picked some file system that would
keep doing that: leave empty files if the system crashed (among lots of other
things).  And that system crashed a lot.  I had the same result as you,
and a lot of additional problems.

Back then we already improved a lot of places that were really really
important (added fsync calls), so the remaining places should be quite
harmless--like this one.  Because of Guix, you can always rebuild
/gnu/store just as it was--after a long build time maybe, but it's possible
(could be made a LOT more usable, though).

(fsync degrades performance, so it makes no sense to fsync for /gnu/store)

I think we can't really do more without imposing undue mainentance burden on
us (for something the file system shouldn't be doing in the first place),
or we could recommend another file system or different file system options
in the manual.  What would the latter be?

Also, how it the world didn't the file system checker fsck

(1) automatically run and
(2) fix this

in your case?

I mean what if those were user documents, which *couldn't* be restored so
easily?  Weird...

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]