-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
create_dir_all can't create directories through a dangling symlink. #31594
Copy link
Copy link
Open
Labels
A-ioArea: `std::io`, `std::fs`, `std::net` and `std::path`Area: `std::io`, `std::fs`, `std::net` and `std::path`C-feature-acceptedCategory: A feature request that has been accepted pending implementation.Category: A feature request that has been accepted pending implementation.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
A-ioArea: `std::io`, `std::fs`, `std::net` and `std::path`Area: `std::io`, `std::fs`, `std::net` and `std::path`C-feature-acceptedCategory: A feature request that has been accepted pending implementation.Category: A feature request that has been accepted pending implementation.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
Currently
create_dir_allfirst does a stat on the file to see if it is a directory, and if not tries to create the parent dirs. This does not take into account that stat can fail if the path is a dangling symlink.The classic
mkdir -pjust tries to create a directory and see why it fails. This spares a syscall and handles dangling symlinks transparently.On Windows this method hit two problems:
create_dir_allfails.You can't mkdir
c:\or\\host\share. But we can just stop recursing in time.We would have to read the symlink (and possibly resolve it if relative), and create the directory
at the target location ourself.
Would it make sense to go trough this trouble?
I think it is best to only fix this for
create_dir_alland to document the normalcreate_dircan notcreate a directory trough a dangling symlink on Windows.