All, We need to think about a new better permissions api for the System.Directory module. The current api and also the implementation are at best useless and possibly harmful. I've been trying to debug various permission problems related to installing files with Cabal on Unix and Windows. Half the problems seem to stem from the permissions api and the copying of permissions in copyFile. data Permissions = Permissions { readable :: Bool, writable :: Bool, executable :: Bool, searchable :: Bool } getPermissions :: FilePath -> IO Permissions setPermissions :: FilePath -> Permissions -> IO () These are clearly designed for the unix permissions model, however they do not map onto it very usefully. get/setPermissions only get the user permissions, not the group or other. So for example if I have a file: -rw-rw-rw- 1 duncan users 0 2009-01-28 12:34 foo then setPermissions "foo" (Permissions True False False False) only removes write permissions from me, not from everyone else: -r--rw-rw- 1 duncan users 0 2009-01-28 12:34 foo which cannot be what we wanted. It's also pretty useless for installing files globally. For that we want to say that a file is readable by everyone and only writable by the owner (usually root). It might even be ok to say only readable by everyone and writable by nobody, but we cannot even do that. Combine that with copyFile copying permissions and we can easily lock people out or install world-writable files depending on the umask of the user building the software. On windows getPermissions tells us almost nothing. In particular if it says the file is readable or writable, this is no guarantee that we can read or write the file. getPermissions does not look at permissions. It only consults the old DOS read-only attribute (and the file extension to tell us if a file is executable). Similarly, on windows setPermissions also only sets the read-only attribute. The read-only attribute should really be avoided. It has rather unhelpful semantics. For example moving a file over a read-only file fails, where as if windows permissions (ACLs) are used then it works as expected (same as on POSIX). The read-only attribute is only there for compatibility with heritage software, we should really never set it. There is also an implementation of copyPermissions, it's not actually exposed in System.Directory but it is used by copyFile. It calls stat to get the permissions and chmod to set them. The implementation is the same between unix and windows, on windows it uses the stat and chmod from the msvcrt library. On Unix copyPermissions does work and is probably the right thing for copyFile to do. It's the default behaviour of /bin/cp for example. However it does mean there is no easy efficient way to make a copy of a file where the destination file gets the default permissions, given the umask of the current user. This means that copyFile is not appropriate for installing files, since the user building a package is not necessarily the same as the one installing it and their umasks can and often are different. The unix install program does not copy permissions, instead it sets them explicitly. We have no portable way of doing the same. But we can at least use the System.Posix.Files.setFileMode to do it. One nice thing about copyFile is that it replaces the destination file atomically. However if we have to set the permissions in a second step then we loose this nice property. Ideally we would create the temporary file in the destination directory (exclusively and with permissions such that no other user could write to our file), we'd copy the data over, set the new destination permissions and atomically replace the destination file. The copyPermissions function on windows is useless. It does not copy permissions. The way that msvcrt implements stat and chmod means that the only "permissions" that are copied is the old DOS read-only attribute. Perhaps copying the read-only attribute is the right thing for copyFile to do, it's what the Win32 CopyFile function does, however it's never what I want to do for installing software package files. So, can we craft a useful api for permissions? We should consider what the defaults for copyfile etc should be with respect to permissions. Where those defaults are not helpful can we think of a way to let us do what we want (eg get default or specific permissions instead of copying permissions). Or is it impossible and we just have to use system-specific functions whenever we need something non-standard. In which case we need to make those functions better, they appear to be mostly lacking for the Win32 case. In either case I'm sure the existing permissions api needs to be deprecated with big flashing warnings. Duncan Oh, and while I'm thinking about it: it's not currently possible to open new/exclusive files with specific permissions and the open temp file functions on windows do not ensure the file is writable only by the current user.