System.Directory has the following: Permissions( Permissions, readable, -- :: Permissions -> Bool writable, -- :: Permissions -> Bool executable, -- :: Permissions -> Bool searchable -- :: Permissions -> Bool ) getPermissions -- :: FilePath -> IO Permissions setPermissions -- :: FilePath -> Permissions -> IO () I propose to deprecate all this, in favour of using platform-specific functionality instead. Here's why: * Most uses of `getPermissions` are wrong. If you use `getPermissions` to predict whether a future operation will fail or not, then the right thing to do is to perform the operation and catch the failure exception. The result of `getPermissions` is immediately stale, and cannot be relied on alone. * The meaning of these operations on Windows is not clear. Windows has a much more elaborate access control model than Unix. For example, permissions can be inherited. Windows' emulation of the Unix `access()` function doesn't support the execute bit, and only has partial support for the other bits. * There doesn't seem to be a good least-common-denominator for access control, so we should provide good platform-specific support instead. (one problem here is that we don't have good platform-specific support for Windows, yet). These functions are hardly ever used. I did a Google code search for setPermissions and aside from implementations of setPermissions itself and tests for it, I came up with: * copying permissions from one file to another. This is used in the implementation of `copyFile`. We can and should do this natively. * one use in Wash * some uses in old versions of Cabal, when installing files (Cabal now uses `copyFile`). There are a few more uses of `getPermissions`, but as pointed out above, these are usually flawed. In any case they can usually be replaced by openFile. This isn't a proper proposal because I haven't written any code, but if we reach agreement in principle, I'll submit a real proposal. Cheers, Simon