System.Directory

System-independent interface to directory manipulation.

Documentation

A directory contains a series of entries, each of which is a named reference to a file system object (file, directory etc.). Some entries may be hidden, inaccessible, or have some administrative function (e.g. . or .. under POSIX), but in this standard all such entries are considered to form part of the directory contents. Entries in sub-directories are not, however, considered to form part of the directory contents.

Each file system object is referenced by a path. There is normally at least one absolute path to each file system object. In some operating systems, it may also be possible to have paths which are relative to the current directory.

Actions on directories

createDirectory :: FilePath -> IO ()

createDirectory dir creates a new directory dir which is initially empty, or as near to empty as the operating system allows.

The operation may fail with:

• isPermissionError / PermissionDenied The process has insufficient privileges to perform the operation. [EROFS, EACCES]
• isAlreadyExistsError / AlreadyExists The operand refers to a directory that already exists. [EEXIST]
• HardwareFault A physical I/O error has occurred. [EIO]
• InvalidArgument The operand is not a valid directory name. [ENAMETOOLONG, ELOOP]
• NoSuchThing There is no path to the directory. [ENOENT, ENOTDIR]
• ResourceExhausted Insufficient resources (virtual memory, process file descriptors, physical disk space, etc.) are available to perform the operation. [EDQUOT, ENOSPC, ENOMEM, EMLINK]
• InappropriateType The path refers to an existing non-directory object. [EEXIST]

createDirectoryIfMissing

Arguments

:: Bool

Create its parents too?

-> FilePath

The path to the directory you want to make

-> IO ()

createDirectoryIfMissing parents dir creates a new directory dir if it doesn't exist. If the first argument is True the function will also create all parent directories if they are missing.

removeDirectory :: FilePath -> IO ()

removeDirectory dir removes an existing directory dir. The implementation may specify additional constraints which must be satisfied before a directory can be removed (e.g. the directory has to be empty, or may not be in use by other processes). It is not legal for an implementation to partially remove a directory unless the entire directory is removed. A conformant implementation need not support directory removal in all situations (e.g. removal of the root directory).

The operation may fail with:

• HardwareFault A physical I/O error has occurred. [EIO]
• InvalidArgument The operand is not a valid directory name. [ENAMETOOLONG, ELOOP]
• isDoesNotExistError / NoSuchThing The directory does not exist. [ENOENT, ENOTDIR]
• isPermissionError / PermissionDenied The process has insufficient privileges to perform the operation. [EROFS, EACCES, EPERM]
• UnsatisfiedConstraints Implementation-dependent constraints are not satisfied. [EBUSY, ENOTEMPTY, EEXIST]
• UnsupportedOperation The implementation does not support removal in this situation. [EINVAL]
• InappropriateType The operand refers to an existing non-directory object. [ENOTDIR]

removeDirectoryRecursive :: FilePath -> IO ()

removeDirectoryRecursive dir removes an existing directory dir together with its contents and subdirectories. Within this directory, symbolic links are removed without affecting their targets.

On Windows, the operation fails if dir is a directory symbolic link.

renameDirectory :: FilePath -> FilePath -> IO ()

renameDirectory old new changes the name of an existing directory from old to new. If the new directory already exists, it is atomically replaced by the old directory. If the new directory is neither the old directory nor an alias of the old directory, it is removed as if by removeDirectory. A conformant implementation need not support renaming directories in all situations (e.g. renaming to an existing directory, or across different physical devices), but the constraints must be documented.

On Win32 platforms, renameDirectory fails if the new directory already exists.

The operation may fail with:

• HardwareFault A physical I/O error has occurred. [EIO]
• InvalidArgument Either operand is not a valid directory name. [ENAMETOOLONG, ELOOP]
• isDoesNotExistError / NoSuchThing The original directory does not exist, or there is no path to the target. [ENOENT, ENOTDIR]
• isPermissionError / PermissionDenied The process has insufficient privileges to perform the operation. [EROFS, EACCES, EPERM]
• ResourceExhausted Insufficient resources are available to perform the operation. [EDQUOT, ENOSPC, ENOMEM, EMLINK]
• UnsatisfiedConstraints Implementation-dependent constraints are not satisfied. [EBUSY, ENOTEMPTY, EEXIST]
• UnsupportedOperation The implementation does not support renaming in this situation. [EINVAL, EXDEV]
• InappropriateType Either path refers to an existing non-directory object. [ENOTDIR, EISDIR]

listDirectory :: FilePath -> IO [FilePath]

listDirectory dir returns a list of all entries in dir without the special entries (. and ..).

The operation may fail with:

• HardwareFault A physical I/O error has occurred. [EIO]
• InvalidArgument The operand is not a valid directory name. [ENAMETOOLONG, ELOOP]
• isDoesNotExistError / NoSuchThing The directory does not exist. [ENOENT, ENOTDIR]
• isPermissionError / PermissionDenied The process has insufficient privileges to perform the operation. [EACCES]
• ResourceExhausted Insufficient resources are available to perform the operation. [EMFILE, ENFILE]
• InappropriateType The path refers to an existing non-directory object. [ENOTDIR]

Since: 1.2.5.0

getDirectoryContents :: FilePath -> IO [FilePath]

Similar to listDirectory, but always includes the special entries (. and ..). (This applies to Windows as well.)

The operation may fail with the same exceptions as listDirectory.

Current working directory

getCurrentDirectory :: IO FilePath

Obtain the current working directory as an absolute path.

In a multithreaded program, the current working directory is a global state shared among all threads of the process. Therefore, when performing filesystem operations from multiple threads, it is highly recommended to use absolute rather than relative paths (see: makeAbsolute).

The operation may fail with:

• HardwareFault A physical I/O error has occurred. [EIO]
• isDoesNotExistError or NoSuchThing There is no path referring to the working directory. [EPERM, ENOENT, ESTALE...]
• isPermissionError or PermissionDenied The process has insufficient privileges to perform the operation. [EACCES]
• ResourceExhausted Insufficient resources are available to perform the operation.
• UnsupportedOperation The operating system has no notion of current working directory.

setCurrentDirectory :: FilePath -> IO ()

Change the working directory to the given path.

In a multithreaded program, the current working directory is a global state shared among all threads of the process. Therefore, when performing filesystem operations from multiple threads, it is highly recommended to use absolute rather than relative paths (see: makeAbsolute).

The operation may fail with:

• HardwareFault A physical I/O error has occurred. [EIO]
• InvalidArgument The operand is not a valid directory name. [ENAMETOOLONG, ELOOP]
• isDoesNotExistError or NoSuchThing The directory does not exist. [ENOENT, ENOTDIR]
• isPermissionError or PermissionDenied The process has insufficient privileges to perform the operation. [EACCES]
• UnsupportedOperation The operating system has no notion of current working directory, or the working directory cannot be dynamically changed.
• InappropriateType The path refers to an existing non-directory object. [ENOTDIR]

withCurrentDirectory

Arguments

:: FilePath

Directory to execute in

-> IO a

Action to be executed

-> IO a

Run an IO action with the given working directory and restore the original working directory afterwards, even if the given action fails due to an exception.

The operation may fail with the same exceptions as getCurrentDirectory and setCurrentDirectory.

Since: 1.2.3.0

Pre-defined directories

getHomeDirectory :: IO FilePath

Returns the current user's home directory.

The directory returned is expected to be writable by the current user, but note that it isn't generally considered good practice to store application-specific data here; use getXdgDirectory or getAppUserDataDirectory instead.

On Unix, getHomeDirectory returns the value of the HOME environment variable. On Windows, the system is queried for a suitable path; a typical path might be C:/Users/<user>.

The operation may fail with:

• UnsupportedOperation The operating system has no notion of home directory.
• isDoesNotExistError The home directory for the current user does not exist, or cannot be found.

data XdgDirectory

Special directories for storing user-specific application data, configuration, and cache files, as specified by the XDG Base Directory Specification.

Note: On Windows, XdgData and XdgConfig map to the same directory.

Since: 1.2.3.0

Constructors

XdgData

For data files (e.g. images). Defaults to ~/.local/share and can be overridden by the XDG_DATA_HOME environment variable. On Windows, it is %APPDATA% (e.g. C:/Users/<user>/AppData/Roaming). Can be considered as the user-specific equivalent of /usr/share.

XdgConfig

For configuration files. Defaults to ~/.config and can be overridden by the XDG_CONFIG_HOME environment variable. On Windows, it is %APPDATA% (e.g. C:/Users/<user>/AppData/Roaming). Can be considered as the user-specific equivalent of /etc.

XdgCache

For non-essential files (e.g. cache). Defaults to ~/.cache and can be overridden by the XDG_CACHE_HOME environment variable. On Windows, it is %LOCALAPPDATA% (e.g. C:/Users/<user>/AppData/Local). Can be considered as the user-specific equivalent of /var/cache.

Instances

Bounded XdgDirectory

Methods

minBound :: XdgDirectory

maxBound :: XdgDirectory

Enum XdgDirectory

Methods

succ :: XdgDirectory -> XdgDirectory

pred :: XdgDirectory -> XdgDirectory

toEnum :: Int -> XdgDirectory

fromEnum :: XdgDirectory -> Int

enumFrom :: XdgDirectory -> [XdgDirectory]

enumFromThen :: XdgDirectory -> XdgDirectory -> [XdgDirectory]

enumFromTo :: XdgDirectory -> XdgDirectory -> [XdgDirectory]

enumFromThenTo :: XdgDirectory -> XdgDirectory -> XdgDirectory -> [XdgDirectory]

Eq XdgDirectory

Methods

(==) :: XdgDirectory -> XdgDirectory -> Bool

(/=) :: XdgDirectory -> XdgDirectory -> Bool

Ord XdgDirectory

Methods

compare :: XdgDirectory -> XdgDirectory -> Ordering

(<) :: XdgDirectory -> XdgDirectory -> Bool

(<=) :: XdgDirectory -> XdgDirectory -> Bool

(>) :: XdgDirectory -> XdgDirectory -> Bool

(>=) :: XdgDirectory -> XdgDirectory -> Bool

max :: XdgDirectory -> XdgDirectory -> XdgDirectory

min :: XdgDirectory -> XdgDirectory -> XdgDirectory

Read XdgDirectory

Methods

readsPrec :: Int -> ReadS XdgDirectory

readList :: ReadS [XdgDirectory]

readPrec :: ReadPrec XdgDirectory

readListPrec :: ReadPrec [XdgDirectory]

Show XdgDirectory

Methods

showsPrec :: Int -> XdgDirectory -> ShowS

show :: XdgDirectory -> String

showList :: [XdgDirectory] -> ShowS

getXdgDirectory

Arguments

:: XdgDirectory

which special directory

-> FilePath

a relative path that is appended to the path; if empty, the base path is returned

-> IO FilePath

Obtain the paths to special directories for storing user-specific application data, configuration, and cache files, conforming to the XDG Base Directory Specification. Compared with getAppUserDataDirectory, this function provides a more fine-grained hierarchy as well as greater flexibility for the user.

It also works on Windows, although in that case XdgData and XdgConfig will map to the same directory.

The second argument is usually the name of the application. Since it will be integrated into the path, it must consist of valid path characters.

Note: The directory may not actually exist, in which case you would need to create it with file mode 700 (i.e. only accessible by the owner).

Since: 1.2.3.0

getAppUserDataDirectory

Arguments

:: FilePath

a relative path that is appended to the path

-> IO FilePath

Obtain the path to a special directory for storing user-specific application data (traditional Unix location). Newer applications may prefer the the XDG-conformant location provided by getXdgDirectory (migration guide).

The argument is usually the name of the application. Since it will be integrated into the path, it must consist of valid path characters.

• On Unix-like systems, the path is ~/.<app>.
• On Windows, the path is %APPDATA%/<app> (e.g. C:/Users/<user>/AppData/Roaming/<app>)

Note: the directory may not actually exist, in which case you would need to create it. It is expected that the parent directory exists and is writable.

The operation may fail with:

• UnsupportedOperation The operating system has no notion of application-specific data directory.
• isDoesNotExistError The home directory for the current user does not exist, or cannot be found.

getUserDocumentsDirectory :: IO FilePath

Returns the current user's document directory.

The directory returned is expected to be writable by the current user, but note that it isn't generally considered good practice to store application-specific data here; use getXdgDirectory or getAppUserDataDirectory instead.

On Unix, getUserDocumentsDirectory returns the value of the HOME environment variable. On Windows, the system is queried for a suitable path; a typical path might be C:/Users/<user>/Documents.

The operation may fail with:

• UnsupportedOperation The operating system has no notion of document directory.
• isDoesNotExistError The document directory for the current user does not exist, or cannot be found.

getTemporaryDirectory :: IO FilePath

Returns the current directory for temporary files.

On Unix, getTemporaryDirectory returns the value of the TMPDIR environment variable or "/tmp" if the variable isn't defined. On Windows, the function checks for the existence of environment variables in the following order and uses the first path found:

• TMP environment variable.
• TEMP environment variable.
• USERPROFILE environment variable.
• The Windows directory

The operation may fail with:

• UnsupportedOperation The operating system has no notion of temporary directory.

The function doesn't verify whether the path exists.

Actions on files

removeFile :: FilePath -> IO ()

removeFile file removes the directory entry for an existing file file, where file is not itself a directory. The implementation may specify additional constraints which must be satisfied before a file can be removed (e.g. the file may not be in use by other processes).

The operation may fail with:

• HardwareFault A physical I/O error has occurred. [EIO]
• InvalidArgument The operand is not a valid file name. [ENAMETOOLONG, ELOOP]
• isDoesNotExistError / NoSuchThing The file does not exist. [ENOENT, ENOTDIR]
• isPermissionError / PermissionDenied The process has insufficient privileges to perform the operation. [EROFS, EACCES, EPERM]
• UnsatisfiedConstraints Implementation-dependent constraints are not satisfied. [EBUSY]
• InappropriateType The operand refers to an existing directory. [EPERM, EINVAL]

renameFile :: FilePath -> FilePath -> IO ()

renameFile old new changes the name of an existing file system object from old to new. If the new object already exists, it is atomically replaced by the old object. Neither path may refer to an existing directory. A conformant implementation need not support renaming files in all situations (e.g. renaming across different physical devices), but the constraints must be documented.

The operation may fail with:

• HardwareFault A physical I/O error has occurred. [EIO]
• InvalidArgument Either operand is not a valid file name. [ENAMETOOLONG, ELOOP]
• isDoesNotExistError / NoSuchThing The original file does not exist, or there is no path to the target. [ENOENT, ENOTDIR]
• isPermissionError / PermissionDenied The process has insufficient privileges to perform the operation. [EROFS, EACCES, EPERM]
• ResourceExhausted Insufficient resources are available to perform the operation. [EDQUOT, ENOSPC, ENOMEM, EMLINK]
• UnsatisfiedConstraints Implementation-dependent constraints are not satisfied. [EBUSY]
• UnsupportedOperation The implementation does not support renaming in this situation. [EXDEV]
• InappropriateType Either path refers to an existing directory. [ENOTDIR, EISDIR, EINVAL, EEXIST, ENOTEMPTY]

copyFile

Arguments

:: FilePath

Source filename

-> FilePath

Destination filename

-> IO ()

Copy a file with its permissions. If the destination file already exists, it is replaced atomically. Neither path may refer to an existing directory. No exceptions are thrown if the permissions could not be copied.

copyFileWithMetadata

Arguments

:: FilePath

Source file

-> FilePath

Destination file

-> IO ()

Copy a file with its associated metadata. If the destination file already exists, it is overwritten. There is no guarantee of atomicity in the replacement of the destination file. Neither path may refer to an existing directory. If the source and/or destination are symbolic links, the copy is performed on the targets of the links.

On Windows, it behaves like the Win32 function CopyFile, which copies various kinds of metadata including file attributes and security resource properties.

On Unix-like systems, permissions, access time, and modification time are preserved. If possible, the owner and group are also preserved. Note that the very act of copying can change the access time of the source file, hence the access times of the two files may differ after the operation completes.

Since: 1.2.6.0

canonicalizePath :: FilePath -> IO FilePath

Make a path absolute and remove as many indirections from it as possible. Indirections include the two special directories . and .., as well as any Unix symbolic links. The input path does not have to point to an existing file or directory.

Note: if you only need an absolute path, use makeAbsolute instead. Most programs should not worry about whether a path contains symbolic links.

Since symbolic links and the special parent directory (..) are dependent on the state of the existing filesystem, the function can only make a conservative attempt by removing symbolic links and .. from the longest prefix of the path that still points to an existing file or directory. If the input path points to an existing file or directory, then the output path shall also point to the same file or directory, provided that the relevant parts of the filesystem have not changed in the meantime (the function is not atomic).

Despite the name, the function does not guarantee canonicity of the returned path due to the presence of hard links, mount points, etc.

Similar to normalise, passing an empty path is equivalent to passing the current directory. The function preserves the presence or absence of the trailing path separator unless the path refers to the root directory /.

Known bug(s): on Windows, the function does not resolve symbolic links.

Changes since 1.2.3.0: The function has been altered to be more robust and has the same exception behavior as makeAbsolute.

makeAbsolute :: FilePath -> IO FilePath

Convert a path into an absolute path. If the given path is relative, the current directory is prepended and then the combined result is normalised. If the path is already absolute, the path is simply normalised. The function preserves the presence or absence of the trailing path separator unless the path refers to the root directory /.

If the path is already absolute, the operation never fails. Otherwise, the operation may fail with the same exceptions as getCurrentDirectory.

Since: 1.2.2.0

makeRelativeToCurrentDirectory :: FilePath -> IO FilePath

Construct a path relative to the current directory, similar to makeRelative.

The operation may fail with the same exceptions as getCurrentDirectory.

findExecutable :: String -> IO (Maybe FilePath)

Given an executable file name, searches for such file in the directories listed in system PATH. The returned value is the path to the found executable or Nothing if an executable with the given name was not found. For example (findExecutable "ghc") gives you the path to GHC.

The path returned by findExecutable corresponds to the program that would be executed by createProcess when passed the same string (as a RawCommand, not a ShellCommand).

On Windows, findExecutable calls the Win32 function SearchPath, which may search other places before checking the directories in PATH. Where it actually searches depends on registry settings, but notably includes the directory containing the current executable. See http://msdn.microsoft.com/en-us/library/aa365527.aspx for more details.

findExecutables :: String -> IO [FilePath]

Given a file name, searches for the file and returns a list of all occurences that are executable.

On Windows, this only returns the first ocurrence, if any. It uses the SearchPath from the Win32 API, so the caveats noted in findExecutable apply here as well.

Since: 1.2.2.0

findExecutablesInDirectories :: [FilePath] -> String -> IO [FilePath]

Given a file name, searches for the file on the given paths and returns a list of all occurences that are executable.

Since: 1.2.4.0

findFile :: [FilePath] -> String -> IO (Maybe FilePath)

Search through the given set of directories for the given file.

findFiles :: [FilePath] -> String -> IO [FilePath]

Search through the given set of directories for the given file and returns a list of paths where the given file exists.

Since: 1.2.1.0

findFileWith :: (FilePath -> IO Bool) -> [FilePath] -> String -> IO (Maybe FilePath)

Search through the given set of directories for the given file and with the given property (usually permissions) and returns the file path where the given file exists and has the property.

Since: 1.2.6.0

findFilesWith :: (FilePath -> IO Bool) -> [FilePath] -> String -> IO [FilePath]

Search through the given set of directories for the given file and with the given property (usually permissions) and returns a list of paths where the given file exists and has the property.

Since: 1.2.1.0

exeExtension :: String

Filename extension for executable files (including the dot if any) (usually "" on POSIX systems and ".exe" on Windows or OS/2).

Since: 1.2.4.0

Existence tests

doesFileExist :: FilePath -> IO Bool

The operation doesFileExist returns True if the argument file exists and is not a directory, and False otherwise.

doesDirectoryExist :: FilePath -> IO Bool

The operation doesDirectoryExist returns True if the argument file exists and is either a directory or a symbolic link to a directory, and False otherwise.

Symbolic links

isSymbolicLink :: FilePath -> IO Bool

Check whether the path refers to a symbolic link. On Windows, this tests for FILE_ATTRIBUTE_REPARSE_POINT.

Since: 1.2.6.0

Permissions

The Permissions type is used to record whether certain operations are permissible on a file/directory. getPermissions and setPermissions get and set these permissions, respectively. Permissions apply both to files and directories. For directories, the executable field will be False, and for files the searchable field will be False. Note that directories may be searchable without being readable, if permission has been given to use them as part of a path, but not to examine the directory contents.

Note that to change some, but not all permissions, a construct on the following lines must be used.

 makeReadable f = do
    p <- getPermissions f
    setPermissions f (p {readable = True})

data Permissions

Instances

Eq Permissions

Methods

(==) :: Permissions -> Permissions -> Bool

(/=) :: Permissions -> Permissions -> Bool

Ord Permissions

Methods

compare :: Permissions -> Permissions -> Ordering

(<) :: Permissions -> Permissions -> Bool

(<=) :: Permissions -> Permissions -> Bool

(>) :: Permissions -> Permissions -> Bool

(>=) :: Permissions -> Permissions -> Bool

max :: Permissions -> Permissions -> Permissions

min :: Permissions -> Permissions -> Permissions

Read Permissions

Methods

readsPrec :: Int -> ReadS Permissions

readList :: ReadS [Permissions]

readPrec :: ReadPrec Permissions

readListPrec :: ReadPrec [Permissions]

Show Permissions

Methods

showsPrec :: Int -> Permissions -> ShowS

show :: Permissions -> String

showList :: [Permissions] -> ShowS

emptyPermissions :: Permissions

readable :: Permissions -> Bool

writable :: Permissions -> Bool

executable :: Permissions -> Bool

searchable :: Permissions -> Bool

setOwnerReadable :: Bool -> Permissions -> Permissions

setOwnerWritable :: Bool -> Permissions -> Permissions

setOwnerExecutable :: Bool -> Permissions -> Permissions

setOwnerSearchable :: Bool -> Permissions -> Permissions

getPermissions :: FilePath -> IO Permissions

The getPermissions operation returns the permissions for the file or directory.

The operation may fail with:

• isPermissionError if the user is not permitted to access the permissions; or
• isDoesNotExistError if the file or directory does not exist.

setPermissions :: FilePath -> Permissions -> IO ()

The setPermissions operation sets the permissions for the file or directory.

The operation may fail with:

• isPermissionError if the user is not permitted to set the permissions; or
• isDoesNotExistError if the file or directory does not exist.

copyPermissions :: FilePath -> FilePath -> IO ()

Timestamps

getAccessTime :: FilePath -> IO UTCTime

Obtain the time at which the file or directory was last accessed.

The operation may fail with:

• isPermissionError if the user is not permitted to read the access time; or
• isDoesNotExistError if the file or directory does not exist.

Caveat for POSIX systems: This function returns a timestamp with sub-second resolution only if this package is compiled against unix-2.6.0.0 or later and the underlying filesystem supports them.

Since: 1.2.3.0

getModificationTime :: FilePath -> IO UTCTime

Obtain the time at which the file or directory was last modified.

The operation may fail with:

• isPermissionError if the user is not permitted to read the modification time; or
• isDoesNotExistError if the file or directory does not exist.

Caveat for POSIX systems: This function returns a timestamp with sub-second resolution only if this package is compiled against unix-2.6.0.0 or later and the underlying filesystem supports them.

setAccessTime :: FilePath -> UTCTime -> IO ()

Change the time at which the file or directory was last accessed.

The operation may fail with:

• isPermissionError if the user is not permitted to alter the access time; or
• isDoesNotExistError if the file or directory does not exist.

Some caveats for POSIX systems:

• Not all systems support utimensat, in which case the function can only emulate the behavior by reading the modification time and then setting both the access and modification times together. On systems where utimensat is supported, the access time is set atomically with nanosecond precision.
• If compiled against a version of unix prior to 2.7.0.0, the function would not be able to set timestamps with sub-second resolution. In this case, there would also be loss of precision in the modification time.

Since: 1.2.3.0

setModificationTime :: FilePath -> UTCTime -> IO ()

Change the time at which the file or directory was last modified.

The operation may fail with:

• isPermissionError if the user is not permitted to alter the modification time; or
• isDoesNotExistError if the file or directory does not exist.

Some caveats for POSIX systems:

• Not all systems support utimensat, in which case the function can only emulate the behavior by reading the access time and then setting both the access and modification times together. On systems where utimensat is supported, the modification time is set atomically with nanosecond precision.
• If compiled against a version of unix prior to 2.7.0.0, the function would not be able to set timestamps with sub-second resolution. In this case, there would also be loss of precision in the access time.

Since: 1.2.3.0