Store path quirks

[roberth]

Is your feature request related to a problem? Please describe.

This is a tracking issue for improving file system support in Nix. This should happen at its own pace. If you're a happy Linux user, please ignore. The purpose of this issue is to start the conversation among those interested.

Context: File systems can have various limitations; some are case insensitive and can not store two nodes that differ only by case. Others may have file name length limits, and Windows is known to reject certain file names characters, and names such as CON. Another is unicode normalization (much like case insensitivity) or a requirement for paths to be valid unicode.

Nix can employ workarounds to allow any NAR to be stored on such file systems without loss of information, but at the cost of build impurities. This allows certain builds that are tolerant of quirks to pass, and it allows any store to be used reliably as a vehicle for nix copy; for instance to reliably perform deployments to systems, including ones whose store does not have the quirk.

Currently, users have little awareness of this and little control over it.

Describe the solution you'd like

Let's define a store path quirk to be a derived property of a store path, that tells us which file system quirks will make it impossible to represent the NAR natively without transformation un such a file system.

• [ ] Have a page in the manual about the known quirks
• [ ] Display store path quirks in nix path-info
• [ ] Display file system quirks in nix store info
• [ ] New advanced derivation attributes to
  • check outputs against specific quirks
  • only allow a derivation to run on a system where the store and/or build directory lack certain quirks
  • perhaps: require inputs or input closures to not have certain quirks
• [ ] As an implementation detail / optimization, save the quirks in the store db and narinfo

Why do this in Nix?

1. The complexity of working around an unsolvable problem should not be hidden - basically the definition of a leaky abstraction. Exposing this complexity to users makes them aware and helps them solve their problems.
2. Once quirk hacks have been applied, a builder can not see reliably that a quirk hack has been applied, as artifacts of the quirk hack may be false positives
3. Nix always processes the tree anyway; may as well derive and store this info, as it's cheap

Describe alternatives you've considered

I think this is a decent sketch, but surely things can be improved.

Additional context

• Case hack

• 9318

Priorities

Add :+1: to issues you find important.

[roberth]

Quirks can also affect directories in the build sandbox, causing build impurities and failures such as https://github.com/NixOS/nix/issues/11595