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
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
|
<title>Boost Filesystem FAQ</title>
<body bgcolor="#FFFFFF">
<h1>
<img border="0" src="../../../boost.png" align="center" width="277" height="86">Filesystem
FAQ</h1>
<p><b>Why base the generic-path string format on POSIX?</b></p>
<p><a href="design.htm#POSIX-01">POSIX</a> is the basis for the most familiar path-string formats, including the
URL portion of URI's and the native Windows format. It is ubiquitous and
familiar. On many systems, it is very easy to implement because it is
either the native operating system format (Unix and Windows) or via a
operating system supplied
POSIX library (z/OS, OS/390, and many more.)</p>
<p><b>Why not use a full URI (Universal Resource Identifier) based path?</b></p>
<p><a href="design.htm#URI">URI's</a> would promise more than the Filesystem Library can actually deliver,
since URI's extend far beyond what most operating systems consider a file or a
directory. Thus for the primary "portable script-style file system
operations" requirement of the Filesystem Library, full URI's appear to be over-specification.</p>
<p><b>Why isn't <i>path</i> a base class with derived <i>directory_path</i> and
<i>file_path</i> classes?</b></p>
<p>Why bother? The behavior of all three classes is essentially identical.
Several early versions did require users to identify each path as a file or
directory path, and this seemed to increase errors and decrease code
readability. There was no apparent upside benefit.</p>
<p><b>Why are fully specified paths called <i>complete</i> rather than <i>
<a name="absolute">absolute</a></i>?</b></p>
<p>To avoid long-held assumptions (what do you mean, <i>"/foo"</i> isn't
absolute on some systems?) by programmers used to single-rooted filesystems.
Using an unfamiliar name for the concept and related functions causes
programmers to read the specs rather than just assuming the meaning is known.</p>
<p><b>Why do some function names have a "native_" prefix?</b></p>
<p>To alert users that the results are inherently non-portable. The names are
deliberately ugly to discourage use except where really necessary.</p>
<p><b>Why not support a concept of specific kinds of file systems, such as
posix_file_system or windows_file_system?</b></p>
<p>Portability is one of the one or two most important requirements for the
library. Gaining some advantage by using features specific to particular
operating systems is not a requirement. There doesn't appear to be much need for
the ability to manipulate, say, a classic Mac OS path while running on an
OpenVMS machine.</p>
<p>Furthermore, concepts like "posix_file_system"
are very slippery. What happens when a NTFS or ISO 9660 file system is mounted
in directory on a machine running a POSIX-like operating system, for example?</p>
<p><b>Why not supply a 'handle' type, and let the file and directory operations
traffic in it?</b></p>
<p>It isn't clear there is any feasible way to meet the "portable script-style
file system operations" requirement with such a system. File systems exist where operations are usually performed on
some non-string handle type. The classic Mac OS has been mentioned explicitly as a case where
trafficking in paths isn't always natural. </p>
<p>The case for the "handle" (opaque data type to identify a file)
style may be strongest for directory iterator value type. (See Jesse Jones' Jan 28,
2002, Boost postings). However, as class path has evolved, it seems sufficient
even as the directory iterator value type.</p>
<p><b>Why aren't directories considered to be files?</b></p>
<p>Because
directories cannot portably and usefully be opened as files using the C++ Standard Library stdio or fstream
I/O facilities. An important additional rationale is that separating the concept
of directories and files makes exposition and specification clearer. A
particular problem is the naming and description of function arguments.</p>
<div align="center">
<center>
<table border="1" cellpadding="5" cellspacing="0">
<tr>
<td colspan="3">
<p align="center"><b>Meaningful Names for Arguments</b></td>
</tr>
<tr>
<td><b>Argument Intent</b></td>
<td><b>Meaningful name if<br>
directories are files</b></td>
<td><b>Meaningful name if<br>
directories aren't files</b></td>
</tr>
<tr>
<td>A path to either a directory or a non-directory</td>
<td align="center"><i>path</i></td>
<td align="center"><i>path</i></td>
</tr>
<tr>
<td>A path to a directory, but not to a non-directory</td>
<td align="center"><i>directory_path</i></td>
<td align="center"><i>directory_path</i></td>
</tr>
<tr>
<td>A path to a non-directory, but not a directory</td>
<td align="center"><i>non_directory_path</i></td>
<td align="center"><i>file_path</i></td>
</tr>
</table>
</center>
</div>
<p>The problem is that when directories are considered files, <i>
non_directory_path</i> as an argument name, and the corresponding "non-directory
path" in documentation, is ugly and lengthy, and so is shortened to just <i>path</i>,
causing the code and documentation to be confusing if not downright wrong. The
names which result from the "directories aren't files" approach are more
acceptable and less likely to be used incorrectly. </p>
<p><b>Why are the operations.hpp non-member functions so low-level?</b></p>
<p>To provide a toolkit from which higher-level functionality can be created.</p>
<p>An
extended attempt to add convenience functions on top of, or as a replacement
for, the low-level functionality failed because there is no widely acceptable
set of simple semantics for most convenience functions considered.
Attempts to provide alternate semantics, via either run-time options or
compile-time polices, became overly complicated in relation to the value
delivered, or became contentious. OTOH, the specific functionality needed for several trial
applications was very easy for the user to construct from the lower-level
toolkit functions. See <a href="design.htm#Abandoned_Designs">Failed Attempts</a>.</p>
<p><b>Isn't it inconsistent then to provide a few convenience functions?</b></p>
<p>Yes, but experience with both this library, POSIX, and Windows indicates
the utility of certain convenience functions, and that it is possible to provide
simple, yet widely acceptable, semantics for them. For example, remove_all.</p>
<p><b>Why are library functions so picky about errors?</b></p>
<p>Safety. The default is to be safe rather than sorry. This is particularly
important given the reality that on many computer systems files and directories
are <a href="index.htm#Race-condition">globally shared</a> resources, and thus subject to
unexpected errors.</p>
<p><b>Why are errors reported by exception rather than return code or error
notification variable?</b></p>
<p>Safety. Return codes or error notification variables are often ignored
by programmers. Exceptions are much harder to ignore, provided desired
default behavior (program termination) if not caught, yet allow error recovery
if desired.</p>
<p><b>Why are attributes accessed via named functions rather than property maps?</b></p>
<p>For a few commonly used attributes (existence, directory or file, emptiness),
simple syntax and guaranteed presence outweigh other considerations. Because
access to virtually all other attributes is inherently system dependent,
property maps are viewed as the best hope for access and modification, but it is
better design to provide such functionality in a separate library. (Historical
note: even the apparently simple attribute "read-only" turned out to be so
system depend as to be disqualified as a "guaranteed presence" operation.)</p>
<p><b>Why isn't there a set_current_directory function?</b></p>
<p>Global variables are considered harmful [<a href="design.htm#Wulf-Shaw-73">wulf-shaw-73</a>].
While we can't prevent people from shooting themselves in the foot, we aren't
about to hand them a loaded gun pointed right at their big toe.</p>
<p><b>Why aren't there query functions for compound conditions like existing_directory?</b></p>
<p>After several attempts, named queries for multi-attribute proved a
slippery-slope; where do you stop?</p>
<p><b>Why aren't <a name="wide-character_names">wide-character names</a> supported? Why not std::wstring or even
a templated type?</b></p>
<p>Wide-character names would provide an illusion of portability where
portability does not in fact exist. Behavior would be completely different on
operating systems (Windows, for example) that support wide-character names, than
on systems which don't (POSIX). Providing functionality that appears to provide
portability but in fact delivers only implementation-defined behavior is highly
undesirable. Programs would not even be portable between library implementations
on the same operating system, let alone portable to different operating systems.</p>
<p>The C++ standards committee Library Working Group discussed this in some
detail both on the committee's library reflector and at the Spring, 2002, <font face="Times New Roman"> meeting</font>, and feels that (1) names based on types other than char are
extremely non-portable, (2) there are no agreed upon semantics for conversion
between wide-character and narrow-character names for file systems which do not support
wide-character name, and
(3) even the committee members most interested in wide-character names are
unsure that they are a good idea in the context of a portable library.</p>
<p>[October, 2002 - PJ Plauger has suggested a locale based conversion
scheme. Others have indicated support for such an experiment.]</p>
<p><b>Why are file and directory name portability errors detected automatically
when these aren't actually errors in some applications?</b></p>
<p>For many uses, automatic portability error detection based on the generic
path grammar is a sensible default. For cases where some other error check
(including no check at all) is preferred for the entire application,
functionality is provided to change the default. For cases where some other
error check (including no check at all) is preferred for a particular
path, the error check can be specified in the path constructor.</p>
<p>The error checking functions call also be explicitly called. That provides
yet another way to check for errors.</p>
<p>The design makes error checking easy and automatic for common cases, yet
provides explicit control when that is required.</p>
<p><b>Why isn't more powerful name portability error detection provided, such as
deferring checking until a path is actually used?</b></p>
<p>A number (at least six) of designs for name validity error
detection were evaluated, including at least four complete implementations.
While the details for rejection differed, all of the more powerful name validity checking
designs distorted other
otherwise simple aspects of the library. While name checking can be helpful, it
isn't important enough to justify added a lot of additional complexity.</p>
<p><b>Why are paths sometimes manipulated by member functions and sometimes by
non-member functions?</b></p>
<p>The design rule is that purely lexical operations are supplied as <i>class
path</i> member
functions, while operations performed by the operating system are provided as
free functions.</p>
<p><b>Why is path <a href="path.htm#Normalized">normalized form</a> different
from <a href="path.htm#Canonical">canonical form</a>?</b></p>
<p>On operating systems such as POSIX which allow symbolic links to directories,
the normalized form of a path can represent a different location than the
canonical form. See <a href="design.htm#symbolic-link-use-case">use case</a>
from Walter Landry.</p>
<hr>
<p>Revised
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->02 August, 2005<!--webbot bot="Timestamp" endspan i-checksum="34600" --></p>
<p> Copyright Beman Dawes, 2002</p>
<p> Use, modification, and distribution are subject to the Boost Software
License, Version 1.0. (See accompanying file <a href="../../../LICENSE_1_0.txt">
LICENSE_1_0.txt</a> or copy at <a href="http://www.boost.org/LICENSE_1_0.txt">
www.boost.org/LICENSE_1_0.txt</a>)</p>
|
