[Issue 10529] rmdirRecurse should have an optional force parameter for read-only file removal

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10529

Vladimir Panteleev <dlang-bugzilla at thecybershadow.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |dlang-bugzilla at thecybershad
                   |                            |ow.net
         Resolution|---                         |WONTFIX

--- Comment #1 from Vladimir Panteleev <dlang-bugzilla at thecybershadow.net> ---
(In reply to Andrej Mitrovic from comment #0)
> however Phobos lacks a 'setFileAttributes' function.

Added in https://github.com/dlang/phobos/pull/1804.

> I propose we add an optional 'force' enum or boolean to rmdirRecurse, 

I tried to add such a parameter to my own library (see forceDelete in
ae.sys.file), and quickly found myself entangled in a hairball of what "force"
really means.

On Windows, aside from the read-only file attribute, you also need to deal with
locked files. Unlike on POSIX, these files cannot be deleted, but they can be
moved, so the code could try renaming it to another location until they are
unlocked. On newer Windows versions, additionally, when attempting to delete a
directory in use by another application, the delete call succeeds, but the
directory remains in its parent directory's file listing, though completely
inaccessible until the program holding the lock on it releases the lock or
exits.

So, it's a mess. I suggest that instead of involving Phobos into this mess,
programs should explicitly deal with those situations that they expect they
will encounter. Arbitrarily needing to delete directories which MIGHT have a
read-only flag set is something that should actually be encountered rarely,
mainly when implementing file managers; in all other cases, the programs should
have some degree of expectations of which files or subdirectories are going to
have the read-only flag set, and deal with that explicitly. Functions which
attempt to "deal" with whatever situation comes up - when in reality most such
situations are going to be predictable - are, as I've learned, an anti-pattern,
and should be avoided.

--