Nix assumes file size reported by fstat is accurate when copying files to the Nix store about nix HOT 4 OPEN

This is hard to support because the NAR file format puts the size of the file before its contents. So if we can't rely on the file size reported by lstat(), we would have to read the entire file into memory first, which would be a problem for supporting large files.

Related: #10019

from nix.

I see. Here's a few thoughts I have on how this could theoretically be solved, note that I don't really know how feasible these are given that I'm not familiar with how Nix works internally:

• Read the file as we do now, but then attempt to continue reading. If this returns more data than expected, keep adding to the NAR file and then seek back to the beginning of the file, updating the size.
  • This wouldn't work if the NAR file is created in a streaming fashion.
• Buffer the entire file into memory or a temporary file if and only if the filesystem reports a size of zero and a read call yields data.
  • This would still break for filesystems that report a non-zero size that is smaller than the actual file size.

Some things to consider:

• What if the filesystem reports a size larger than the actual file? Would this lead to an invalid NAR file being generated, or an error being emitted? We may be able to employ a strategy similar to what I've first suggested above.
• How to handle infinitely large files? What should we do if someone attempts to use, for example, /dev/random? Should we have a hard limit on how large a file can be? Should we have this limit only for files that report a zero-size?

from nix.

Triaged in Nix team meeting:

• @roberth: we could special-case the 0. if the size is reported as 0, we could still try reading it and buffer it.

  • @edolstra: at least that would work. wonder what POSIX has to say what should happen if the file size is not reported correctly (these files do exist, such as /proc)

• @edolstra: we used to buffer essentially entire files in memory, but that simply doesn't scale

  • it could be done, but it's hard to do in constant-space memory

• This wouldn't work if the NAR file is created in a streaming fashion.

  @Ericson2314: It is created in a streaming fashion, we wish to use constant space and often create NARs directly into a sink like a pipe or socket.

• This mismatch between actual file size and reported file size is considered absolutely legal under Linux (citation needed)

  @Ericson2314: We would love to see that citation :)

from nix.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2024-05-15-nix-team-meeting-minutes-146/45491/1

from nix.