Skip to content
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

remove_items silently fails on broken symlinks #78

Open
ukautz opened this issue Jan 29, 2024 · 0 comments
Open

remove_items silently fails on broken symlinks #78

ukautz opened this issue Jan 29, 2024 · 0 comments

Comments

@ukautz
Copy link

ukautz commented Jan 29, 2024

Currently fs_extra::remove_items does not act on symlinks that point to not-existing targets. It is not clear from the documentation what the intended behavior is, so I am not sure if this asks for fixing, or just documenting.

Reproduce

Assume a directory that contains symlinks, both to existing and non-existing targets:

mkdir dir/
touch dir/file-1
ln -s dir/file-1 dir/link-1
ln -s dir/file-2 dir/link-2

A minimal rust program for reproduction:

fn main() {
    for arg in std::env::args().skip(1) {
        let path = Path::new(&arg);
        println!("Removing path {:?}", path);
        match fs_extra::remove_items(&[path]) {
            Ok(_) => println!(" -> OK"),
            Err(err) => println!(" -> Err: {}", err)
        }
    }
}

And then:

$ tree dir
dir
├── file-1
├── link-1 -> file-1
└── link-2 -> file-2

1 directory, 3 files


$ cargo run -- dir/link*
Removing path "dir/link-1"
 -> OK
Removing path "dir/link-2"
 -> OK


$ tree dir              
dir
├── file-1
└── link-2 -> file-2

1 directory, 2 files

(above tested on MacOS and Linux)

Expected

Up to the maintainers of the library:

  1. Remove All: Delete all provided paths. Here: link-1 and link-2 are both removed. file-1 stays (unchanged).
  2. Document Symlink: Be clear that remove_items has caveat (or maybe more broadly: recommend not to use with symlinks?)
  3. Error: Return an error in case symlink is "unclean" (is that a thing?)

I think (1) makes the most sense. Alas this was my expectation when using remove_items.

Causal

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant