<html>

<head>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>Filesystem FAQ</title>
<link rel="stylesheet" type="text/css" href="../../../../doc/src/minimal.css">
</head>

<body>

<table border="0" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="710">
  <tr>
    <td width="277">
<a href="../../../../index.htm">
<img src="../../../../boost.png" alt="boost.png (6897 bytes)" align="middle" width="277" height="86" border="0"></a></td>
    <td width="410" align="middle">
    <font size="7">Filesystem Library</font>
    </td>
  </tr>
</table>

<table border="0" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" bgcolor="#D7EEFF" width="100%">
  <tr>
    <td><a href="../../../../index.htm">Boost Home</a>&nbsp;&nbsp;&nbsp;
    <a href="index.htm">Library Home</a>&nbsp; &nbsp;
    <a href="index.htm#tutorial">Tutorial</a>&nbsp; &nbsp; <a href="reference.html">
    Reference</a>&nbsp;&nbsp; <a href="faq.htm">FAQ</a></td>
  </tr>
</table>

<h1>
Frequently Asked Questions</h1>
<p><b>Why base the generic-path string format on POSIX?</b></p>
<p><a href="design.htm#POSIX-01">[POSIX-01]</a> is an ISO Standard. It is the basis for the most familiar path-string formats, 
not just for POSIX systems but also for the native Windows format and the 
URL portion of URI's. It is ubiquitous and 
familiar.&nbsp; 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.&nbsp; Thus for the primary &quot;portable script-style file system 
operations&quot; 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?&nbsp; 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>&quot;/foo&quot;</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 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 most important requirements for the 
library.&nbsp;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 &quot;file system&quot; 
are very slippery. What happens when a NTFS or FAT file system is mounted 
in directory on a machine running a POSIX-like operating system, for example? 
Some of the POSIX API's may return very un-POSIX like results.</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 &quot;portable script-style 
file system operations&quot; 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.&nbsp;&nbsp;&nbsp; </p>
<p>The case for the &quot;handle&quot; (opaque data type to identify a file) 
style may be strongest for directory iterator value type.&nbsp; (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 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.&nbsp; 
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.&nbsp; OTOH, the specific functionality needed for several trial 
applications was very easy for the user to construct from the lower-level 
toolkit functions.&nbsp; 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 there basic_directory_iterator&lt;&gt; overloads for operations.hpp 
predicate functions? Isn't two ways to do the same thing poor design?</b></p>
<p>Yes, two ways to do the same thing is often a poor design practice. But the 
iterator versions are often much more efficient. Calling status() during 
iteration over a directory containing 15,000 files took 6 seconds for the path 
overload, and 1 second for the iterator overload, for tests on a freshly booted 
machine. Times were .90 seconds and .30 seconds, for tests after prior use of 
the directory. This performance gain is large enough to justify deviating from 
preferred design practices. Neither overload alone meets all needs.</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="#global">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.&nbsp;Return codes or error notification variables are often ignored 
by programmers.&nbsp; Exceptions are much harder to ignore, provided desired 
default behavior (program termination) if not caught, yet allow error recovery 
if desired. Non-throwing versions of functions are provided where experience 
indicates the need.</p>
<p><b>Why are attributes accessed via named functions rather than property maps?</b></p>
<p>For  commonly used attributes (existence, directory or file, emptiness), 
simple syntax and guaranteed presence outweigh other considerations. Because 
access to many 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 &quot;read-only&quot; turned out to be so 
system depend as to be disqualified as a &quot;guaranteed presence&quot; operation.)</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>They <u>are</u> supported, starting with version 1.33. See
<a href="i18n.html">Internationalization</a>.</p>
<p><b>Why isn't automatic name portability error detection provided?</b></p>
<p>A number (at least six) of designs for  name validity error 
detection were evaluated, including at least four complete implementations.&nbsp; 
While the details for rejection differed, all of the more powerful name validity checking 
designs distorted other 
otherwise simple aspects of the library. Even the simple name checking provided 
in prior library versions was a constant source of user complaints. 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 
basic_path</i> member 
functions, while operations performed by the operating system are provided as 
free functions.</p>
<hr>
<p>Revised
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan -->18 March, 2008<!--webbot bot="Timestamp" endspan i-checksum="29005" --></p>
<p>© Copyright Beman Dawes, 2002</p>
<p> Use, modification, and distribution are subject to the Boost Software 
License, Version 1.0. See <a href="http://www.boost.org/LICENSE_1_0.txt">
www.boost.org/LICENSE_1_0.txt</a></p>