Proposal: Make Permissions type abstract

[Duncan Coutts]

On 23 June 2010 21:44, Ian Lynagh <igloo at earth.li> wrote:

> 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