On 23 June 2010 21:44, Ian Lynagh
I think we would be better served by the Permissions type being abstract in System.Directory, with the unix and Win32 packages providing the real definition, and some system-specific functions on it. This would allow the generic get/set functions to implement copyPermissions.
This proposal just does the step which has most potential to cause problems for packages that use the type: It makes the type abstract in System.Directory (and adds explicit setter functions, so no functionality is lost).
I support making it abstract as a first step. There are several places in Cabal where the current portable permissions API is unsuitable for the task at hand. For a bit more background see: http://haskell.org/pipermail/libraries/2009-February/011334.html I suggest that we be more explicit about what the query and update functions should mean. setReadable, setWritable, setExecutable, setSearchable :: Bool -> Permissions -> Permissions For example, should we assume that readable (setReadable v perms) = v I suggest not. If the query functions gives us the effective permissions but the setters only set the owner permissions then under an ACL permission system we would not necessarily expect the above to hold. Similarly, executable permissions don't really exist on windows so perhaps executable always returns true for .exe files and setting executable permissions is simply ignored. I suggest we say that the query functions report the effective permissions (e.g. will we be able to read or write this file). For the update functions we have a choice. Currently setPermissions on Unix only sets the owner permissions, group and other permissions are unaffected. Perhaps for this proposal we should stick with that. Though in that case perhaps we should be more explicit with the names and leave room for the future: setOwnerReadable, setOwnerWritable, setOwnerExecutable, setOwnerSearchable :: Bool -> Permissions -> Permissions We will need to think about how this maps to windows ACLs. The current setPermissions on Windows does not consider ACLs at all, IIRC it just looks at the DOS read-only attribute (and setting all other permissions are ignored). Since it ignores ACLs it doesn't actually report whether a file is readable or writable accurately. Duncan