1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
|
%**<title>The Haskell 98 Library Report: Directory functions</title>
%**~header
%% Other useful functions from SML 96 include modification time
%% and path-testing (is this a full path/real path).
\section{Directory Functions}
\index{directories}
\index{the file system}
\outline{
\inputHS{headers/Directory}
}
\indextt{createDirectory}\indextt{removeDirectory}\indextt{removeFile}
\indextt{renameDirectory}\indextt{renameFile}
\indextt{getDirectoryContents}\indextt{getCurrentDirectory}
\indextt{setCurrentDirectory}
These functions operate on directories in the file system.
Any @Directory@ operation could raise an @isIllegalOperation@, as
described in Section~\ref{IOError}; all other permissible errors are
described below. Note that, in particular, if an implementation does
not support an operation it should raise an @isIllegalOperation@.
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 (for instance, ``.'' or ``..'' under POSIX), but 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. Although there may be
file system objects other than files and directories, this library
does not distinguish between physical files and other non-directory
objects. All such objects should therefore be treated as if they are files.
Each file system object is referenced by a {\it path}\index{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.
Computation @createDirectory@~"dir" creates a new directory "dir" which is
initially empty, or as near to empty as the operating system allows.
\index{making directories}
{\em Error~reporting}.
The @createDirectory@ computation may fail with:
@isPermissionError@ if the user is not permitted to create the directory;
@isAlreadyExistsError@ if the directory already exists; or @isDoesNotExistError@ if
the new directory's parent does not exist.
Computation @removeDirectory@~"dir" removes an existing directory
"dir"\index{deleting directories}\index{removing directories}. The
implementation may specify additional constraints which must be
satisfied before a directory can be removed (for instance, 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 (for instance, removal of the root
directory).
Computation @removeFile@~"file" removes the directory entry for an existing
file "file", where "file" is not itself a directory\index{deleting
files}\index{removing files}. The implementation may specify additional
constraints which must be satisfied before a file can be removed (for instance, the
file may not be in use by other processes).
{\em Error~reporting}.
The @removeDirectory@ and @removeFile@ computations may fail with:
@isPermissionError@ if the user is not permitted to remove the file/directory;
or @isDoesNotExistError@ if the file/directory does not exist.
Computation @renameDirectory@~"old"~"new" changes the name of an existing
directory from "old" to "new"\index{renaming directories}\index{moving
directories}. 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 (for instance, renaming to an
existing directory, or across different physical devices), but the
constraints must be documented.
Computation @renameFile@~"old"~"new" changes the name of an existing file
system object from "old" to "new"\index{renaming files}\index{moving files}.
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
(for instance, renaming across different physical devices), but the constraints must be
documented.
{\em Error~reporting}.
The @renameDirectory@ and @renameFile@ computations may fail with:
@isPermissionError@ if the user is not permitted to rename the file/directory,
or if either argument to @renameFile@ is a directory;
or @isDoesNotExistError@ if the file/directory does not exist.
Computation @getDirectoryContents@~"dir" returns a list of {\em all} entries
in "dir"\index{reading a directory}.
Each entry in the returned list is named relative to the directory "dir", not as an absolute path.
If the operating system has a notion of current directories,
@getCurrentDirectory@ returns an absolute path to the
current directory of the calling process\index{current directory}.
{\em Error~reporting}.
The @getDirectoryContents@ and @getCurrentDirectory@ computations may fail with:
@isPermissionError@ if the user is not permitted to access the directory;
or @isDoesNotExistError@ if the directory does not exist.
If the operating system has a notion of current directories,
@setCurrentDirectory@~"dir" changes the current directory of the
calling process to "dir"\index{changing the directory}\index{setting the directory}.
{\em Error~reporting}.
@setCurrentDirectory@ may fail with:
@isPermissionError@ if the user is not permitted to change directory
to that specified;
or @isDoesNotExistError@ if the directory does not exist.
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.
\bprog
@
makeReadable f = do
p <- getPermissions f
setPermissions f (p {readable = True})
@
\eprog
The operation @doesDirectoryExist@ returns @True@ if the argument file
exists and is a directory, and @False@ otherwise. The operation @doesFileExist@ returns @True@
if the argument file exists and is not a directory, and @False@ otherwise.
The @getModificationTime@ operation returns the
clock time at which the file/directory was last modified.
{\em Error~reporting}.
@get(set)Permissions@,
@doesFile(Directory)Exist@,
and @getModificationTime@
may fail with:
@isPermissionError@ if the user is not permitted to access
the appropriate information;
or @isDoesNotExistError@ if the file/directory does not exist.
The @setPermissions@
computation may also fail with:
@isPermissionError@ if the user is not permitted to change
the permission for the specified file or directory;
or @isDoesNotExistError@ if the file/directory does not exist.
% Duplicates the first case above, and would require
% extensive consistency checking throughout. KH
% The @doesFileExist@ and @doesDirectoryExist@ computations
% may also fail with @isPermissionError@ if some part of the path
% to the file/directory cannot be searched.
%**~footer
|
