Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check for and repair bad .links entries #3230

Merged
merged 1 commit into from Nov 26, 2019

Conversation

chkno
Copy link
Member

@chkno chkno commented Nov 15, 2019

A corrupt entry in .links prevents adding a fixed version of that file
to the store in any path. The user experience is that corruption
present in the store 'spreads' to new paths added to the store:

(With store optimisation enabled)

  1. A file in the store gets corrupted somehow (eg: filesystem bug).
  2. The user tries to add a thing to the store which contains a good copy
    of the corrupted file.
  3. The file being added to the store is hashed, found to match the bad
    .links entry, and is replaced by a link to the bad .links entry.
    (The .links entry's hash is not verified during add -- this would
    impose a substantial performance burden.)
  4. The user observes that the thing in the store that is supposed to be
    a copy of what they were trying to add is not a correct copy -- some
    files have different contents! Running "nix-store --verify
    --check-contents --repair" does not fix the problem.

This change makes "nix-store --verify --check-contents --repair" fix
this problem. Bad .links entries are simply removed, allowing future
attempts to insert a good copy of the file to succeed.

This addresses the problem described in #1281, but requires a
full-store verify & repair rather than just --repair-path.

A corrupt entry in .links prevents adding a fixed version of that file
to the store in any path.  The user experience is that corruption
present in the store 'spreads' to new paths added to the store:

(With store optimisation enabled)

1. A file in the store gets corrupted somehow (eg: filesystem bug).
2. The user tries to add a thing to the store which contains a good copy
   of the corrupted file.
3. The file being added to the store is hashed, found to match the bad
   .links entry, and is replaced by a link to the bad .links entry.
   (The .links entry's hash is not verified during add -- this would
   impose a substantial performance burden.)
4. The user observes that the thing in the store that is supposed to be
   a copy of what they were trying to add is not a correct copy -- some
   files have different contents!  Running "nix-store --verify
   --check-contents --repair" does not fix the problem.

This change makes "nix-store --verify --check-contents --repair" fix
this problem.  Bad .links entries are simply removed, allowing future
attempts to insert a good copy of the file to succeed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants