June 25, 2017
https://issues.dlang.org/show_bug.cgi?id=10529

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

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

--- Comment #1 from Vladimir Panteleev <dlang-bugzilla@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.

--