Replace call to stat, lstat, and maybeLstat with appropriate functions from std::filesystem
#10937
Conversation
...with `std::filesystem` functions The `stat` defined in `file-system.cc` is not used anywhere now. This will be removed with the removal of the `STAT` macro defined in the same file. `lstat` is still used in some places so we cannot remove the `STAT` macro.
the `maybeLstat` is removed in favor of the new `maybeSymlinkStat` which uses the `std::filesystem` library. All the call sites have been updated
... `unix::lstat` appropriate functions from `std::filesystem` is used in places where `lstat` was called. Places that require platform specific implementation are using `unix::lstat` for now.
- The `std::filesystem::status` returns `not_found` and does not throw any error. - `std::filesystem::*` is shortened to `fs::*` for better readability
The result of this function cannot be `std::filesystem::file_status` yet as we use it to acess `st_mtime`. The equivalent function in `std::filesystem` to get the last write time does follow symlinks which is not the behavior we want.
siddhantk232
requested review from
thufschmitt,
Ericson2314 and
edolstra
as code owners
github-actions
bot
added
new-cli
A typo (`"src" -> "dst"`) caught by functional tests is fixed
The removed `nix::maybeLstat` was referenced here. It's replaced with the new function that replaced it.
| try { | ||
| fs::permissions(src, st.permissions() | fs::perms::owner_write, permOpts); | ||
| } catch (const fs::filesystem_error & e) { | ||
| throw SysError("setting permissions on '%s'", src); |
There was a problem hiding this comment.
Does SysError actually work correctly after a std::filesystem exception? I don't know if it's guaranteed to leave errno in a known state.
There was a problem hiding this comment.
The documentation says that fs::filesystem_error is only thrown on OS errors so I think it's safe to assume that the errno is appropriately set when we're in this catch block?
There was a problem hiding this comment.
That's probably a safe assumption on Unix-like systems, but I'm not sure if it's the case on Windows. Maybe @Ericson2314 knows?
There was a problem hiding this comment.
We can use
- https://en.cppreference.com/w/cpp/error/system_error/code to get the code
- https://en.cppreference.com/w/cpp/error/error_code/value to get the Unix err code
- https://hydra.nixos.org/build/264900059/download/1/html/classnix_1_1SysError.html#ae7e9f454d2fc92588de15bcef87ec8c4 to construct a
SysErrorwith an explicitly givenerrNo
There was a problem hiding this comment.
I suppose on windows we than get these long error codes instead?
There was a problem hiding this comment.
@Ericson2314 I have changed the code to use the SysError with explicit errNo (see e0090fe)
src/libutil/file-system.cc
Outdated
| @@ -196,11 +184,24 @@ std::optional<struct stat> maybeLstat(const Path & path) | |||
| } | |||
| return st; | |||
| } | |||
| #endif | |||
|
|
|||
| std::optional<fs::file_status> maybeSymlinkStat(const Path & path) | |||
There was a problem hiding this comment.
Given that we're changing this function anyway, can we change path to be a std::filesystem::path?
There was a problem hiding this comment.
Why is this function called maybeSymlinkStat and the other maybeLstat? Seems inconsistent.
There was a problem hiding this comment.
Why is this function called maybeSymlinkStat and the other maybeLstat? Seems inconsistent.
The unix::maybeLstat (and unix::lstat) will be removed very soon. The places where it's used currently demand specific functions (getDeviceIdOfFile and getLastWriteTime for example) which I'll soon implement.
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2024-06-24-nix-team-meeting-minutes-155/47739/1 |
Motivation
The cpp
std::filesystemhas functions that we can use in place ofstatandlstat. This makes the code more portable between windows and unix.Some places where it required windows native implementation are still using
unix::lstat(the oldlstatjust moved inside the newunixnamespace). Alternative windows implementation needs to be written to tackle these situations.Context
Priorities and Process
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.