Store optimisation hard-links non-identical files, corrupting store

[amarshall]

Describe the bug

Files that should not be hard-linked together get hard-linked. In particular for the case I saw, files that should have been empty files (8000+) were hard-linked to a non-empty file.

If I had to guess (and this is just a guess!), there was a race where store optimisation analyzed a file between its creation and having content written to it, and decided to hard-link it to the empty file. Once content was written, all other empty files became non-empty.

Steps to reproduce

Unclear.

Expected behavior

Hard links to only link identical files.

Metadata

nix-env (Nix) 2.31.2 on aarch64-darwin

Additional context

auto-optimise-store is disabled. Store optimisation runs in a scheduled job. nix store repair --all remedied the corrupt files, making them empty again.

Checklist

• checked latest Nix manual (source)
• checked open bug issues and pull requests for possible duplicates

---

Add 👍 to issues you find important.

[Frontear]

Do you have any settings in nix.conf for the following:

• fsync-metadata
• fsync-store-paths
• sync-before-registering

Are you able to consistently reproduce this in some way? If so, could you try enabling all 3 of the aforementioned options, then reproducing things?

[amarshall]

Unfortunately I don’t have a reproducer as it just “happened” and I only noticed because I was getting odd build failures due to unexpected file contents. As I suspect it is a race, that would also make it challenging.

fsync-metadata is set to true, but the others are false (these are the defaults, it seems).

[amarshall]

I also don’t think I had any system crashes, so I’m not sure fsync would have helped?