-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Made remove_dir_all
work as documented when directory is a symlink
#29412
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Previously the function worked correctly only when symlink is inside of a directory, not when path is a symlink itself. This patch also eliminates the `lstat()` call on most systems because `DirEntry::file_type` is enough both to detect if entry is a dir and if entry is a symlink.
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @brson (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
@@ -1069,13 +1069,23 @@ pub fn remove_dir_all<P: AsRef<Path>>(path: P) -> io::Result<()> { | |||
} | |||
|
|||
fn _remove_dir_all(path: &Path) -> io::Result<()> { | |||
let filetype = try!(symlink_metadata(path)).file_type(); | |||
if filetype.is_symlink() { | |||
remove_file(path) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure this will work correctly on Windows; a symlink isn't always a file on Windows.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, the code that removed a symlink inside the directory used remove_file
too, AFAICS. So at least it's not a regression.
Anyway, it would be helpful if someone can test it on windows.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've confirmed that directory symlinks on windows cannot be removed by remove_file
but can be removed via remove_dir
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that this may want to also use is_dir
to choose whether to recurse or not (like below). Junctions on Windows (e.g. hard links to directories) don't report is_dir
, but to behave the same as unix we should delete their contents.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that this may want to also use is_dir to choose whether to recurse or not (like below). Junctions on Windows (e.g. hard links to directories) don't report is_dir, but to behave the same as unix we should delete their contents.
Isn't it a contradiction? If they don't report is_dir
how should we know to recurse?
The question probably is: is_dir() && is_symlink()
(impossible on unix) should recurse or remove_dir()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, it looks like impossible combination on windows too:
https://github.com/rust-lang/rust/blob/master/src/libstd/sys/windows/fs.rs#L429
So probably I must stat symlink on windows to find out whether it's a directory. And then if it's a directory do (non-recursive) remove_dir
. Right? According to wikipedia, junctions are removed with rmdir
(i.e. non-recursive)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove_dir()
seems like the answer which is most consistent with other forms of symbolic links.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm yes I think I may have gotten a little confused, I'll have to think on this a bit.
I’d like to see a test which tests whether function behaviour is as expected. A “make-run” test probably would be the least painful one to do. |
_remove_dir_all_unchecked(path) | ||
} | ||
} | ||
fn _remove_dir_all_unchecked(path: &Path) -> io::Result<()> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's fine to remove the leading underscore here, the convention above is just because it's paired with a sibling remove_dir_all
function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also this may be best with a _recursive
prefix here instead of _unchecked
There is a test, function called "recursive_rmdir_of_symlink"
Well, what is a "make-run" test? |
Ah, ignore me then. I should go to sleep instead of reviewing more PRs, I guess. |
try!(remove_dir_all(&*child)); | ||
let child = try!(child); | ||
let child_path = child.path(); | ||
let mut child_type = try!(child.file_type()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should fall back to calling symlink_metadata
in the case file_type()
failed (as it's not guaranteed to work across all platforms right now)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICS, fallback is already inside DirEntry: https://github.com/rust-lang/rust/blob/master/src/libstd/sys/unix/fs.rs#L186 (unix), on windows it looks like it always work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, right! I forgot about that, carry on!
* Renamed internal method `*_unchecked` -> `*_recursive` * Better windows support (untested)
Okay, I've renamed the method and added some windows support. Unfortunately, windows support is untested. But I've included few provisional tests for windows. Hopefully @bors will run the tests for me. Speaking about windows: I do |
Just so you know, you cannot actually create any symbolic links in the tests because that requires administrator privileges on Windows for some obscure reason. Directory junctions and hard links are fine, just not symbolic links. |
Well, so I should remove the tests back again. @retep998, does |
Hard links are for files only while junctions are for directories only. Also hard links are not reparse points. |
@retep998, any way to create a junction in rust? |
try!(remove_file(&*child)); | ||
if cfg!(windows) { | ||
if child_type.is_symlink() { | ||
let target_type = try!(metadata(&*child_path)).file_type(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested this out a bit, and oddly enough I'm not sure we can use this function to determine this. Using metadata
will resolve all intermediate symlinks, showing the file type of the actual destination file. This ends up having what I think are two problems:
- If the symlink is broken (e.g. the destination is gone), I don't think this will work.
- Removal of the symlink depends on what kind of symlink was created, not the destination itself.
I found that I could create a symlink to a file with symlink_dir
, but I could only remove the symlink with remove_dir
. I think that we may have enough information in the DirEntry
itself to figure this out (via a private API for now).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found that I could create a symlink to a file with
symlink_dir
,
That's because Windows doesn't check the target of symbolic links when you create them. You still created a directory symbolic link. It just happens to be pointing at a file.
What's the status of this PR? |
Well, it works on linux. But it seems I don't have a time to work on windows stuff. And as I've already written I can't test anyway. |
☔ The latest upstream changes (presumably #31360) made this pull request unmergeable. Please resolve the merge conflicts. |
cc @pitdicker you may be interested in this as well! |
Yes I am :) |
@pitdicker, never mind. I'm happy someone fixes it :) Closing in favor of #31468 |
Previously the function worked correctly only when symlink is inside of
a directory, not when path is a symlink itself.
This patch also eliminates the
lstat()
call on most systems becauseDirEntry::file_type
is enough both to detect if entry is a dir and ifentry is a symlink.
I'm not sure if the
#[cfg(not(windows))]
and the comment above is still actual. Can't test patch on windows.This supercedes #29324