]>
Commit | Line | Data |
---|---|---|
7c673cae FG |
1 | <html> |
2 | ||
3 | <head> | |
4 | <meta http-equiv="Content-Language" content="en-us"> | |
5 | <meta name="GENERATOR" content="Microsoft FrontPage 5.0"> | |
6 | <meta name="ProgId" content="FrontPage.Editor.Document"> | |
7 | <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> | |
8 | <title>Filesystem FAQ</title> | |
9 | <link href="styles.css" rel="stylesheet"> | |
10 | </head> | |
11 | ||
12 | <body> | |
13 | ||
14 | <table border="0" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111"> | |
15 | <tr> | |
16 | <td width="277"> | |
17 | <a href="../../../index.htm"> | |
18 | <img src="../../../boost.png" alt="boost.png (6897 bytes)" align="middle" width="300" height="86" border="0"></a></td> | |
19 | <td align="middle"> | |
20 | <font size="7">Filesystem FAQ</font> | |
21 | </td> | |
22 | </tr> | |
23 | </table> | |
24 | ||
25 | <table border="0" cellpadding="5" cellspacing="0" style="border-collapse: collapse" | |
26 | bordercolor="#111111" bgcolor="#D7EEFF" width="100%"> | |
27 | <tr> | |
28 | <td><a href="index.htm">Home</a> | |
29 | <a href="tutorial.html">Tutorial</a> | |
30 | <a href="reference.html">Reference</a> | |
31 | <a href="faq.htm">FAQ</a> | |
32 | <a href="release_history.html">Releases</a> | |
33 | <a href="portability_guide.htm">Portability</a> | |
34 | <a href="v3.html">V3 Intro</a> | |
35 | <a href="v3_design.html">V3 Design</a> | |
36 | <a href="deprecated.html">Deprecated</a> | |
37 | <a href="issue_reporting.html">Bug Reports </a> | |
38 | </td> | |
39 | </table> | |
40 | ||
41 | <h1> | |
42 | Frequently Asked Questions</h1> | |
43 | <h2>General questions</h2> | |
44 | <p><b>Why not support a concept of specific kinds of file systems, such as posix_file_system or windows_file_system.</b></p> | |
45 | <p>Portability is one of the most important requirements for the | |
46 | library. Features specific to a particular operating system or file system | |
47 | can always be accessed by using the operating system's API.</p> | |
48 | ||
49 | <h2> | |
50 | Class <code><font size="6">path</font></code> questions </h2> | |
51 | <p><b>Why base the generic pathname format on POSIX?</b></p> | |
52 | <p><a href="design.htm#POSIX-01">POSIX</a> is an ISO Standard. It is the basis for the most familiar | |
53 | pathname formats, | |
54 | not just for POSIX-based operating systems but also for Windows and the | |
55 | URL portion of URI's. It is ubiquitous and | |
56 | familiar. On many systems, it is very easy to implement because it is | |
57 | either the native operating system format (Unix and Windows) or via a | |
58 | operating system supplied | |
59 | POSIX library (z/OS, OS/390, and many more.)</p> | |
60 | <p><b>Why not use a full URI (Universal Resource Identifier) based path?</b></p> | |
61 | <p><a href="design.htm#URI">URI's</a> would promise more than the Filesystem Library can actually deliver, | |
62 | since URI's extend far beyond what most operating systems consider a file or a | |
63 | directory. Thus for the primary "portable script-style file system | |
64 | operations" requirement of the Filesystem Library, full URI's appear to be over-specification.</p> | |
65 | <p><b>Why isn't <i>path</i> a base class with derived <i>directory_path</i> and | |
66 | <i>file_path</i> classes?</b></p> | |
67 | <p>Why bother? The behavior of all three classes is essentially identical. | |
68 | Several early versions did require users to identify each path as a file or | |
69 | directory path, and this seemed to increase coding errors and decrease code | |
70 | readability. There was no apparent upside benefit.</p> | |
71 | <p><b>Why do path decomposition functions yielding a single element return a | |
72 | path rather than a string?</b></p> | |
73 | <p>Interface simplicity. If they returned strings, flavors would be needed for | |
74 | <code>string</code>, <code>wstring</code>, <code>u16string</code>, <code> | |
75 | u32string</code>, and generic strings.</p> | |
76 | <p><b>Why don't path member functions have overloads with error_code& arguments?</b></p> | |
77 | <p>They have not been requested by users; the need for error reporting via | |
78 | error_code seems limited to operations failures rather than path failures.</p> | |
79 | <h2>Operations function questions</h2> | |
80 | <p><b>Why not supply a 'handle' type, and let the file and directory operations | |
81 | traffic in it?</b></p> | |
82 | <p>It isn't clear there is any feasible way to meet the "portable script-style | |
83 | file system operations" requirement with such a system. File systems exist where operations are usually performed on | |
84 | some non-string handle type. The classic Mac OS has been mentioned explicitly as a case where | |
85 | trafficking in paths isn't always natural. </p> | |
86 | <p>The case for the "handle" (opaque data type to identify a file) | |
87 | style may be strongest for directory iterator value type. (See Jesse Jones' Jan 28, | |
88 | 2002, Boost postings). However, as class path has evolved, it seems sufficient | |
89 | even as the directory iterator value type.</p> | |
90 | <p><b>Why are the operations functions so low-level?</b></p> | |
91 | <p>To provide a toolkit from which higher-level functionality can be created.</p> | |
92 | <p>An | |
93 | extended attempt to add convenience functions on top of, or as a replacement | |
94 | for, the low-level functionality failed because there is no widely acceptable | |
95 | set of simple semantics for most convenience functions considered. | |
96 | Attempts to provide alternate semantics via either run-time options or | |
97 | compile-time polices became overly complicated in relation to the value | |
98 | delivered, or became contentious. OTOH, the specific functionality needed for several trial | |
99 | applications was very easy for the user to construct from the lower-level | |
100 | toolkit functions. See <a href="design.htm#Abandoned_Designs">Failed | |
101 | Attempts</a>.</p> | |
102 | <p><b>Isn't it inconsistent then to provide a few convenience functions?</b></p> | |
103 | <p>Yes, but experience with both this library, POSIX, and Windows, indicates | |
104 | the utility of certain convenience functions, and that it is possible to provide | |
105 | simple, yet widely acceptable, semantics for them. For example, <code>remove_all()</code>.</p> | |
106 | <p><b>Why are there directory_iterator overloads for operations.hpp | |
107 | predicate functions? Isn't two ways to do the same thing poor design?</b></p> | |
108 | <p>Yes, two ways to do the same thing is often a poor design practice. But the | |
109 | iterator versions are often much more efficient. Calling status() during | |
110 | iteration over a directory containing 15,000 files took 6 seconds for the path | |
111 | overload, and 1 second for the iterator overload, for tests on a freshly booted | |
112 | machine. Times were .90 seconds and .30 seconds, for tests after prior use of | |
113 | the directory. This performance gain is large enough to justify deviating from | |
114 | preferred design practices. Neither overload alone meets all needs.</p> | |
115 | <p><b>Why are the operations functions so picky about errors?</b></p> | |
116 | <p>Safety. The default is to be safe rather than sorry. This is particularly | |
117 | important given the reality that on many computer systems files and directories | |
118 | are globally shared resources, and thus subject to | |
119 | race conditions.</p> | |
120 | <p><b>Why are attributes accessed via named functions rather than property maps?</b></p> | |
121 | <p>For commonly used attributes (existence, directory or file, emptiness), | |
122 | simple syntax and guaranteed presence outweigh other considerations. Because | |
123 | access to many other attributes is inherently system dependent, | |
124 | property maps are viewed as the best hope for access and modification, but it is | |
125 | better design to provide such functionality in a separate library. (Historical | |
126 | note: even the apparently simple attribute "read-only" turned out to be so | |
127 | system depend as to be disqualified as a "guaranteed presence" operation.)</p> | |
128 | <p><b>Why isn't automatic name portability error detection provided?</b></p> | |
129 | <p>A number (at least six) of designs for name validity error | |
130 | detection were evaluated, including at least four complete implementations. | |
131 | While the details for rejection differed, all of the more powerful name validity checking | |
132 | designs distorted other | |
133 | otherwise simple aspects of the library. Even the simple name checking provided | |
134 | in prior library versions was a constant source of user complaints. While name checking can be helpful, it | |
135 | isn't important enough to justify added a lot of additional complexity.</p> | |
136 | <p><b>Why are paths sometimes manipulated by member functions and sometimes by | |
137 | non-member functions?</b></p> | |
138 | <p>The design rule is that purely lexical operations are supplied as <i>class | |
139 | path</i> member | |
140 | functions, while operations performed by the operating system are provided as | |
141 | free functions.</p> | |
142 | <hr> | |
143 | <p>Revised | |
144 | <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->29 December, 2014<!--webbot bot="Timestamp" endspan i-checksum="38652" --></p> | |
145 | <p>© Copyright Beman Dawes, 2002</p> | |
146 | <p> Use, modification, and distribution are subject to the Boost Software | |
147 | License, Version 1.0. See <a href="http://www.boost.org/LICENSE_1_0.txt"> | |
148 | www.boost.org/LICENSE_1_0.txt</a></p> |