[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30875: Garbage collector may leave empty files

From: Ludovic Courtès
Subject: bug#30875: Garbage collector may leave empty files
Date: Wed, 21 Mar 2018 00:09:29 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)


Marius Bakke <address@hidden> skribis:

> Recently I've seen a couple of instances like these:
> exporting path 
> `/gnu/store/mi1rbw8fdsbi4bc4pndbb6smq39722vm-baobab-3.26.1.tar.xz'
> guix offload: error: build failed: hash of path 
> `/gnu/store/mi1rbw8fdsbi4bc4pndbb6smq39722vm-baobab-3.26.1.tar.xz' has 
> changed from 
> `4223b4813b2253e68ea2b824d0d0e284ff75714ad0faf5a33d65a78df6b65915' to 
> `77ac62e2629d8e45f624589c0c8bf99e24b3a722349bf1e79bc186008534e246'!
> cannot build derivation 
> `/gnu/store/jbx6a4n1d55dpydr87d11m7xwapm3pcx-gnome-3.24.3.drv': 1 
> dependencies couldn't be built
> Without the build hook, it manifests as:
> starting phase `unpack'
> tar: This does not look like a tar archive
> xz: (stdin): File format not recognized
> tar: Child returned status 1
> tar: Error is not recoverable: exiting now
> There was another instance on help-guix recently with a user having
> empty .drv files in the store.
> There is a bug lurking here somewhere, but I'm not sure where to start
> looking.
> $ find /gnu/store/ -maxdepth 1 -size 0 | grep -v '\.lock$' | wc -l
> 24

Are we sure this is a Guix issue and not a disk or file system
corruption issue?  The relevant code in guix-daemon hasn’t changed in

What file system are you using?  Btrfs?  :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]