std::fs::remove_dir_all fails if any of the intermediate file deletions fails with ENOENT

[tbu-]

rust/library/std/src/sys/pal/unix/fs.rs

Line 2144 in d819876

cvt(unsafe { unlinkat(fd, child_name.as_ptr(), 0) })?;

rust/library/std/src/sys/pal/unix/fs.rs

Lines 2156 to 2159 in d819876

	// unlink the directory after removing its contents
	cvt(unsafe {
	unlinkat(parent_fd.unwrap_or(libc::AT_FDCWD), path.as_ptr(), libc::AT_REMOVEDIR)
	})?;

[tgross35]

Are you suggesting that this should continue removing files if one fails but still report an error, or that specifically ENOENT on a file should be considered a success?

I assume this can happen if racing with another removal operation, not sure if there is a precedent for what to do here (rm?).

@rustbot label +T-libs +C-bug +O-unix +A-filesystem -needs-triage

[tgross35]

Just checked what rm does when this happens (by making a lot of files and having two rms race), it indeed ignores ENOENT:

...
unlinkat(4, "768458", 0)                = -1 ENOENT (No such file or directory)
unlinkat(4, "768461", 0)                = 0
unlinkat(4, "768463", 0)                = -1 ENOENT (No such file or directory)
unlinkat(4, "768472", 0)                = 0
unlinkat(4, "768476", 0)                = -1 ENOENT (No such file or directory)
unlinkat(4, "768479", 0)                = -1 ENOENT (No such file or directory)
unlinkat(4, "768485", 0)                = -1 ENOENT (No such file or directory)
unlinkat(4, "768490", 0)                = -1 ENOENT (No such file or directory)
unlinkat(4, "768496", 0)                = -1 ENOENT (No such file or directory)
unlinkat(4, "768501", 0)                = 0
unlinkat(4, "768504", 0)                = 0
unlinkat(4, "768506", 0)                = 0
...
$ echo $?
0

So doing the same seems probably fine here, think this should be pretty easy. Ideally this should have a regression test, I'm not sure what the best way to do that is - @tbu- how did you identify or reproduce this?

@rustbot label +E-easy

[tbu-]

I looked at the code for TOCTOU issues and found this particular problem. Nothing automatable I'm afraid.

[tbu-]

Are you suggesting that this should continue removing files if one fails but still report an error, or that specifically ENOENT on a file should be considered a success?

Specifically ENOENT should be considered a success.

I assume this can happen if racing with another removal operation, not sure if there is a precedent for what to do here (rm?).

Yes, this is about racing. E.g. std::fs::create_dir_all also succeeds when EEXISTS is returned for mkdir.

[ChrisDenton]

This seems like it's just an implementation bug so fixes would be welcome. On Windows we do ignore not found errors when deleting files in remove_dir_all.

[lolbinarycat]

@rustbot claim