Proposal: Make Permissions type abstract
Hi all, Proposal: Make Permissions type abstract Ticket: http://hackage.haskell.org/trac/ghc/ticket/4149 The Permissions type in System.Directory aims to be a lowest-common-denominator type. This makes it unsuitable for some tasks. For example, a copyPermissions primitive had to be implemented, as it is not possible to use the getPermissions and setPermissions functions to copy the permissions from one file to another: $ ls -l foo* -rwxr-x-wx 1 ian ian 0 Jun 23 21:27 foo1 ---------- 1 ian ian 0 Jun 23 21:27 foo2 ---------- 1 ian ian 0 Jun 23 21:27 foo3 $ hd -e 'System.Directory.copyPermissions "foo1" "foo2"' $ hd -e 'System.Directory.getPermissions "foo1" >>= System.Directory.setPermissions "foo3"' $ ls -l foo* -rwxr-x-wx 1 ian ian 0 Jun 23 21:27 foo1 -rwxr-x-wx 1 ian ian 0 Jun 23 21:27 foo2 -rwx------ 1 ian ian 0 Jun 23 21:27 foo3 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). (patch is in the ticket) The type is also exported in Haskell 98's Directory module. I think this should get its own copy of the type. Suggested discussion deadline: 9 July 2010. Thanks Ian
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
Ian Lynagh wrote:
Proposal: Make Permissions type abstract Ticket: http://hackage.haskell.org/trac/ghc/ticket/4149
+1. It is possible that this will still break some packages. Do we know how many packages, and which, are potentially affected? In any case that is good to know, and we should make sure all maintainers know about this proposal. More breakage may ensue as the platform-dependent APIs begin to diverge. Thanks, Yitz
On Mon, Jun 28, 2010 at 06:47:59PM +0300, Yitzchak Gale wrote:
Ian Lynagh wrote:
Proposal: Make Permissions type abstract Ticket: http://hackage.haskell.org/trac/ghc/ticket/4149
+1.
It is possible that this will still break some packages. Do we know how many packages, and which, are potentially affected?
Sorry for the slow reply. I've updated the patch with Duncan's suggestion of setOwner* names, and done a hackage regression run with that patch (and removing the export from haskell98's Directory). Both with and without the patches, of 2219 packages, cabal can make an install plan for 920, and 590 are actually buildable. i.e. 0 packages are affected, as far as I can tell. Thanks Ian
participants (3)
-
Duncan Coutts -
Ian Lynagh -
Yitzchak Gale