Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: NixOS/nix
base: 272c4ba36dab
Choose a base ref
...
head repository: NixOS/nix
compare: 74a1bfdcab03
Choose a head ref
  • 4 commits
  • 5 files changed
  • 2 contributors

Commits on Apr 29, 2020

  1. builtins.readFile: do not truncate content

    This closes #3026 by allowing `builtins.readFile` to read a file with a
    wrongly reported file size, for example, files in `/proc` may report a
    file size of 0. Reading file in `/proc` is not a good enough motivation,
    however I do think it just makes nix more robust by allowing more file
    to be read.  Especially, I do considerer the previous behavior to be
    dangerous because nix was previously reading truncated files. Examples
    of file system which incorrectly report file size may be network file
    system or dynamic file system (for performance reason, a dynamic file
    system such as FUSE may generate the content of the file on demand).
    
    ```
    nix-repl> builtins.readFile "/proc/version"
    ""
    ```
    
    With this commit:
    
    ```
    nix-repl> builtins.readFile "/proc/version"
    "Linux version 5.6.7 (nixbld@localhost) (gcc version 9.3.0 (GCC)) #1-NixOS SMP Thu Apr 23 08:38:27 UTC 2020\n"
    ```
    
    Here is a summary of the behavior changes:
    
    - If the reported size is smaller, previous implementation
    was silently returning a truncated file content. The new implementation
    is returning the correct file content.
    
    - If a file had a bigger reported file size, previous implementation was
    failing with an exception, but the new implementation is returning the
    correct file content. This change of behavior is coherent with this pull
    request.
    
    Open questions
    
    - The behavior is unchanged for correctly reported file size, however
    performances may vary because it uses the more complex sink interface.
    Considering that sink is used a lot, I don't think this impacts the
    performance a lot.
    - `builtins.readFile` on an infinite file, such as `/dev/random` may
    fill the memory.
    - it does not support adding file to store, such as `${/proc/version}`.
    guibou committed Apr 29, 2020
    Copy the full SHA
    5a34a47 View commit details
    Browse the repository at this point in the history
  2. Remove the drain argument from readFile

    Now it is always `drain` (see previous commit).
    guibou committed Apr 29, 2020
    Copy the full SHA
    7afcb5a View commit details
    Browse the repository at this point in the history
  3. StringSink pre allocate

    When used with `readFile`, we have a pretty good heuristic of the file
    size, so `reserve` this in the `string`. This will save some allocation
    / copy when the string is growing.
    guibou committed Apr 29, 2020
    Copy the full SHA
    2e5be2a View commit details
    Browse the repository at this point in the history

Commits on May 6, 2020

  1. Merge pull request #3546 from guibou/nix_readfile_on_0_sized_files

    builtins.readFile: do not truncate content
    edolstra committed May 6, 2020
    Copy the full SHA
    74a1bfd View commit details
    Browse the repository at this point in the history