[ruby-core:121491] [Ruby Feature#18784] `FileUtils.rm_f` and `FileUtils.rm_rf` should not mask exceptions

Issue #18784 has been updated by deivid (David Rodr=EDguez).


I realized I never replied to latest objections from @mame to this feature.

My use case is to make sure temporary test files and folders are cleaned af=
ter each test, because if they are not cleaned the following tests may not =
work as expected, since they rely on starting with an empty tmp folder. I'm=
 not sure if that's "1) delete target at all costs" or "2) delete target if=
 possible". I think it's "2), but raise an error if not possible".

The kind of swallowed issues I've run into in the past are things like:
* Keyword vs positional parameter error due to accidentally using a version=
 of FileUtils not supported by my version of Ruby.
* ENAMETOOLONG errors due to a bug in Ruby.

Things I definitely wanted to know about because they made my tmp test fold=
er not removed and affected subsequent specs in hard to debug ways.

For these issues, `FileUtils.rm_rf` raising an error and not swallowing it =
would've helped, I didn't need any further retry/sleep/chmod manipulations,=
 and they would have not helped my use case (because they would have not ma=
de any difference).

By the way, I believe `FileUtils.rm_rf` on Windows seems to already have so=
me of this chmod+retry behaviour @mame was mentioning: https://github.com/r=
uby/fileutils/blob/636975a184f07ccef31a0ffd9412be8fbb75e087/lib/fileutils.r=
b#L2336-L2355. I don't need nor like this behavior, but just mentioning it.

In any case, I decided to stick to using `FileUtils.rm_r` and make sure I d=
on't pass folders that don't exist as targets. That already has the exact b=
ehavior I'm asking for, so I'm fine with this issue being closed.

----------------------------------------
Feature #18784: `FileUtils.rm_f` and `FileUtils.rm_rf` should not mask exce=
ptions
https://bugs.ruby-lang.org/issues/18784#change-112511

* Author: deivid (David Rodr=EDguez)
* Status: Open
----------------------------------------
In recent times, I've been having issues with these methods because they do=
n't let you know when some issue happened while trying to remove the given =
folders/files.

IMO most users expect all pre-existing folders/files that are passed to the=
se methods to be actually removed by the methods. Instead, when this happen=
s, errors are silently swallowed and normally the result is that you will g=
et some other issue further down the road, making the problem hard to debug.

The current workaround I'm using is to double check whether the files still=
 exist after the method, and raise a custom error if they do, but I still c=
an't see the original problem, so issues are similarly hard to debug.

This is also a deviation from how `rm -rf` and `rm -f` work, since these to=
ols finish with a failure exit code when they fail to remove the given file=
s. Given that `fileutils` is intended to mimic shell functionality, I think=
 this is just a bug.

I think the intention of the `force` flag here is to:
* Don't prompt for confirmation.
* Ignore given arguments that are not files that already exist.

But any issue other than that should not be swallowed, and in general I thi=
nk the method should succeed if and only if the given list of file names do=
es not exist after the methods are done.

I think this is in line with the following note I get when I run `man rm`, =
but also suggests that this is not the standard behavior of "historical imp=
lementations"

> COMPATIBILITY
>
> The rm utility differs from historical implementations in that the -f opt=
ion only masks attempts to remove non-existent files instead of masking a l=
arge variety of errors.

I implemented this at https://github.com/ruby/fileutils/pull/58, but treati=
ng this as a bug. I can also implement a more conservative for approach for=
 users that might be using `FileUtils.rm_rf` or `FileUtils.rm_f` but don't =
really care if the files are removed or not.

Alternative proposals would be `FileUtils.rm_rf(force: strict)`, or `FileUt=
ils.strict_rm_rf`, but to be honest, if this is considered a breaking chang=
e, I would ship it as a new major version, and let users update their code =
to swallow errors themselves if they need to.

Happy to hear any feedback!



--=20
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.rub=
y-lang.org/