Bug 10529 – rmdirRecurse should have an optional force parameter for read-only file removal

On win32 rmdirRecurse will fail if a file in the directory has the read-only attribute set. The win32 API says such a file needs to have its read-only attribute removed, however Phobos lacks a 'setFileAttributes' function. I propose we add an optional 'force' enum or boolean to rmdirRecurse, which will force removal of read-only files by removing the read-only attribute. This probably means other related functions like 'remove' will need to have this optional parameter. Additionally we should provide a setAttributes function

(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.