Re: Getting rid of "source file [...] newer than compiled" messages

[Ricardo Wurmus <rekado@elephly.net>]

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:
>>
>>> Gosh, I am embarassed. The compiled files are indeed in the path Guile
>>> was helpfully trying to point me at:
>>>
>>> #+BEGIN_EXAMPLE
>>>   $ ls -a /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/
>>>   .  ..  base16.go  base64.go  common.go  hash.go  hmac.go  package-config.go  pk-crypto.go  random.go  utils.go
>>> #+END_EXAMPLE
>>>
>>> So I went back and took Ricardo's advice and looked at the time's involved:
>>>
>>> #+BEGIN_EXAMPLE
>>>   $ stat /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm
>>>     File: ‘/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm’
>>>     Size: 5366      	Blocks: 16         IO Block: 4096   regular file
>>>   Device: fc02h/64514d	Inode: 137942      Links: 1
>>>   Access: (0444/-r--r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
>>>   Access: 2019-04-10 09:29:22.008888969 -0500
>>>   Modify: 2018-12-25 17:02:43.755150339 -0600
>>>   Change: 2018-12-25 17:02:43.755150339 -0600
>>>    Birth: -
>>> #+END_EXAMPLE
>>>
>>> #+BEGIN_EXAMPLE
>>>   $ stat /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go
>>>     File: ‘/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go’
>>>     Size: 77485     	Blocks: 152        IO Block: 4096   regular file
>>>   Device: fc02h/64514d	Inode: 137925      Links: 1
>>>   Access: (0444/-r--r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
>>>   Access: 2019-04-06 16:56:32.259721626 -0500
>>>   Modify: 2018-12-25 17:02:43.753150336 -0600
>>>   Change: 2018-12-25 17:02:43.753150336 -0600
>>>    Birth: -
>>> #+END_EXAMPLE
>>>
>>> It looks like the scheme file is fractions of a second newer than the
>>> compiled file. So, pulling on this thread:
>>
>> These time stamps are wrong.  Everything in /gnu/store should have 0 for
>> the mtime.
>
> Perhaps I missed a flag when unpacking the store initially?

Maybe.  But subsequent calls to “guix pull” should give you new store
items anyway, and those should be fine.

Is there anything special about your setup perhaps?  E.g. running the
daemon as some other user than root, using btrfs, etc.

>>> 2. I feel like, regardless of the root-cause, some Guix command should
>>>    be able to correct this issue for me, without necessarily having to
>>>    know what went wrong or why.
>>
>> This shouldn’t ever happen, because all store items should have their
>> mtime reset.
>>
>> You previously mentioned that you modified your store (which “voids your
>> warranty” as it were); by default the store is bind-mounted to ensure
>> that it is read-only.  Can you tell us more about the file system and
>> the way the store is mounted?
>
> I previously mentioned I was considering modifying the store as a fix to
> this issue. To my recollection, I don't think I've manually touched the
> store yet.

Okay.

> I still hold the opinion that the guix toolchain should be able to heal
> store items, regardless of how they got that way, or whether it should
> be theoretically possible. Do you disagree?

No, I agree with you.  That’s one of the reasons why “guix gc
--verify=repair,contents” exists.

--
Ricardo