Boost-Commit mailing page: [Boost-commit] svn:boost r50951 - in sandbox/filesystem-v3: . libs/filesystem libs/filesystem/doc

Date view	Thread view	Subject view	Author view

Subject: [Boost-commit] svn:boost r50951 - in sandbox/filesystem-v3: . libs/filesystem libs/filesystem/doc
From: bdawes_at_[hidden]
Date: 2009-02-01 09:38:13

Author: bemandawes
Date: 2009-02-01 09:38:12 EST (Sun, 01 Feb 2009)
New Revision: 50951
URL: http://svn.boost.org/trac/boost/changeset/50951

Log:
Filesystem.v3: docs organization work-in-progress
Added:
   sandbox/filesystem-v3/libs/filesystem/doc/design.htm (contents, props changed)
   sandbox/filesystem-v3/libs/filesystem/doc/faq.htm (contents, props changed)
   sandbox/filesystem-v3/libs/filesystem/doc/index.htm (contents, props changed)
   sandbox/filesystem-v3/libs/filesystem/doc/portability_guide.htm (contents, props changed)
   sandbox/filesystem-v3/libs/filesystem/index.html (contents, props changed)
Removed:
   sandbox/filesystem-v3/index.html
   sandbox/filesystem-v3/libs/filesystem/readme-sandbox-v3.html
Text files modified:
   sandbox/filesystem-v3/libs/filesystem/doc/v3_design.html | 41 ++++++++++++++++++++++++++++-----------
   1 files changed, 29 insertions(+), 12 deletions(-)

Deleted: sandbox/filesystem-v3/index.html
==============================================================================
--- sandbox/filesystem-v3/index.html 2009-02-01 09:38:12 EST (Sun, 01 Feb 2009)
+++ (empty file)
@@ -1,22 +0,0 @@
-<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 Version 3</title>
-</head>
-
-<body>
-
-<h1>Filesystem Version 3 in the Sandbox</h1>
-To experiment with filesystem.v3:
-<ul>
- <li>Subversion checkout filesystem-v3 from the sandbox.</li>
- <li>Subversion export trunk to the same directory.</li>
-</ul>
-
-</body>
-
-</html>
\ No newline at end of file

Added: sandbox/filesystem-v3/libs/filesystem/doc/design.htm
==============================================================================
--- (empty file)
+++ sandbox/filesystem-v3/libs/filesystem/doc/design.htm 2009-02-01 09:38:12 EST (Sun, 01 Feb 2009)
@@ -0,0 +1,353 @@
+<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>Boost Filesystem Library Design</title>
+</head>
+
+<body bgcolor="#FFFFFF">
+
+<h1>
+<img border="0" src="../../../boost.png" align="center" width="277" height="86">Filesystem
+Library Design</h1>
+
+Introduction 
+Requirements 
+Realities 
+Rationale 
+Abandoned_Designs 
+References
+
+<h2><a name="Introduction">Introduction</a></h2>
+
+The primary motivation for beginning work on the Filesystem Library was
+frustration with Boost administrative tools.  Scripts were written in
+Python, Perl, Bash, and Windows command languages.  There was no single
+scripting language familiar and acceptable to all Boost administrators. Yet they
+were all skilled C++ programmers - why couldn't C++ be used as the scripting
+language?
+
+The key feature C++ lacked for script-like applications was the ability to
+perform portable filesystem operations on directories and their contents. The
+Filesystem Library was developed to fill that void.
+
+The intent is not to compete with traditional scripting languages, but to
+provide a solution for situations where C++ is already the language
+of choice..
+
+<h2><a name="Requirements">Requirements</a></h2>
+<ul>
+ <li>Be able to write portable script-style filesystem operations in modern
+ C++. 
+ 
+ Rationale: This is a common programming need. It is both an
+ embarrassment and a hardship that this is not possible with either the current
+ C++ or Boost libraries.  The need is particularly acute
+ when C++ is the only toolset allowed in the tool chain.  File system
+ operations are provided by many languages used on multiple platforms,
+ such as Perl and Python, as well as by many platform specific scripting
+ languages. All operating systems provide some form of API for filesystem
+ operations, and the POSIX bindings are increasingly available even on
+ operating systems not normally associated with POSIX, such as the Mac, z/OS,
+ or OS/390. 
+ </li>
+ <li>Work within the realities described below. 
+ 
+ Rationale: This isn't a research project. The need is for something that works on
+ today's platforms, including some of the embedded operating systems
+ with limited file systems. Because of the emphasis on portability, such a
+ library would be much more useful if standardized. That means being able to
+ work with a much wider range of platforms that just Unix or Windows and their
+ clones. 
+ </li>
+ <li>Avoid dangerous programming practices. Particularly, all-too-easy-to-ignore error notifications
+ and use of global variables. If a dangerous feature is provided, identify it as such. 
+ 
+ Rationale: Normally this would be covered by "the usual Boost requirements...",
+ but it is mentioned explicitly because the equivalent native platform and
+ scripting language interfaces often depend on all-too-easy-to-ignore error
+ notifications and global variables like "current
+ working directory". 
+ </li>
+ <li>Structure the library so that it is still useful even if some functionality
+ does not map well onto a given platform or directory tree. Particularly, much
+ useful functionality should be portable even to flat
+(non-hierarchical) filesystems. 
+ 
+ Rationale: Much functionality which does not
+ require a hierarchical directory structure is still useful on flat-structure
+ filesystems.  There are many systems, particularly embedded systems,
+ where even very limited functionality is still useful.</li>
+</ul>
+<ul>
+ <li>Interface smoothly with current C++ Standard Library input/output
+ facilities.  For example, paths should be
+ easy to use in std::basic_fstream constructors. 
+ 
+ Rationale: One of the most common uses of file system functionality is to
+ manipulate paths for eventual use in input/output operations. 
+ Thus the need to interface smoothly with standard library I/O. 
+ </li>
+ <li>Suitable for eventual standardization. The implication of this requirement
+ is that the interface be close to minimal, and that great care be take
+ regarding portability. 
+ 
+ Rationale: The lack of file system operations is a serious hole
+ in the current standard, with no other known candidates to fill that hole.
+ Libraries with elaborate interfaces and difficult to port specifications are much less likely to be accepted for
+ standardization. 
+ </li>
+ <li>The usual Boost <a href="http://www.boost.org/more/lib_guide.htm">requirements and
+ guidelines</a> apply. 
+ </li>
+ <li>Encourage, but do not require, portability in path names. 
+ 
+ Rationale: For paths which originate from user input it is unreasonable to
+ require portable path syntax. 
+ </li>
+ <li>Avoid giving the illusion of portability where portability in fact does not
+ exist. 
+ 
+ Rationale: Leaving important behavior unspecified or "implementation defined" does a
+ great disservice to programmers using a library because it makes it appear
+ that code relying on the behavior is portable, when in fact there is nothing
+ portable about it. The only case where such under-specification is acceptable is when both users and implementors know from
+ other sources exactly what behavior is required, yet for some reason it isn't
+ possible to specify it exactly.</li>
+</ul>
+<h2><a name="Realities">Realities</a></h2>
+<ul>
+ <li>Some operating systems have a single directory tree root, others have
+ multiple roots. 
+ </li>
+ <li>Some file systems provide both a long and short form of filenames. 
+ </li>
+ <li>Some file systems have different syntax for file paths and directory
+ paths. 
+ </li>
+ <li>Some file systems have different rules for valid file names and valid
+ directory names. 
+ </li>
+ <li>Some file systems (ISO-9660, level 1, for example) use very restricted
+ (so-called 8.3) file names. 
+ </li>
+ <li>Some operating systems allow file systems with different
+ characteristics to be "mounted" within a directory tree.  Thus a
+ ISO-9660 or Windows
+ file system may end up as a sub-tree of a POSIX directory tree. 
+ </li>
+ <li>Wide-character versions of directory and file operations are available on some operating
+ systems, and not available on others. 
+ </li>
+ <li>There is no law that says directory hierarchies have to be specified in
+ terms of left-to-right decent from the root. 
+ </li>
+ <li>Some file systems have a concept of file "version number" or "generation
+ number".  Some don't. 
+ </li>
+ <li>Not all operating systems use single character separators in path names.  Some use
+ paired notations. A typical fully-specified OpenVMS filename
+ might look something like this: 
+ 
+ <code>   DISK$SCRATCH:[GEORGE.PROJECT1.DAT]BIG_DATA_FILE.NTP;5 
+ </code> 
+ The general OpenVMS format is: 
+ 
+    
+ Device:[directories.dot.separated]filename.extension;version_number 
+ </li>
+ <li>For common file systems, determining if two descriptors are for same
+ entity is extremely difficult or impossible.  For example, the concept of
+ equality can be different for each portion of a path - some portions may be
+ case or locale sensitive, others not. Case sensitivity is a property of the
+ pathname itself, and not the platform. Determining collating sequence is even
+ worse. 
+ </li>
+ <li>Race-conditions may occur. Directory trees, directories, files, and file attributes are in effect shared between all threads, processes, and computers which have access to the
+ filesystem.  That may well include computers on the other side of the
+ world or in orbit around the world. This implies that file system operations
+ may fail in unexpected ways. For example: 
+ 
+ <code>     assert( exists("foo") == exists("foo") );
+ // may fail! 
+     assert( is_directory("foo") == is_directory("foo");
+ // may fail! 
+ </code> 
+ In the first example, the file may have been deleted between calls to
+ exists().  In the second example, the file may have been deleted and then
+ replaced by a directory of the same name between the calls to is_directory(). 
+ </li>
+ <li>Even though an application may be portable, it still will have to traffic
+ in system specific paths occasionally; user provided input is a common
+ example. 
+ </li>
+ <li><a name="symbolic-link-use-case">Symbolic</a> links cause canonical and
+ normal form of some paths to represent different files or directories. For
+ example, given the directory hierarchy <code>/a/b/c</code>, with a symbolic
+ link in <code>/a</code> named <code>x</code>  pointing to <code>b/c</code>,
+ then under POSIX Pathname Resolution rules a path of <code>"/a/x/.."</code>
+ should resolve to <code>"/a/b"</code>. If <code>"/a/x/.."</code> were first
+ normalized to <code>"/a"</code>, it would resolve incorrectly. (Case supplied
+ by Walter Landry.)</li>
+</ul>
+
+<h2><a name="Rationale">Rationale</a></h2>
+
+The Requirements and <a href="#Realities">
+Realities</a> above drove much of the C++ interface design.  In particular,
+the desire to make script-like code straightforward caused a great deal of
+effort to go into ensuring that apparently simple expressions like exists( "foo"
+) work as expected.
+
+See the FAQ for the rationale behind many detailed
+design decisions.
+
+Several key insights went into the path class design:
+<ul>
+ <li>Decoupling of the input formats, internal conceptual (vector<string>
+ or other sequence)
+ model, and output formats.</li>
+ <li>Providing two input formats (generic and O/S specific) broke a major
+ design deadlock.</li>
+ <li>Providing several output formats solved another set of previously
+ intractable problems.</li>
+ <li>Several non-obvious functions (particularly decomposition and composition)
+ are required to support portable code. (Peter Dimov, Thomas Witt, Glen
+ Knowles, others.)</li>
+</ul>
+
+Error checking was a particularly difficult area. One key insight was that
+with file and directory names, portability isn't a universal truth. 
+Rather, the programmer must think out the question "What operating systems do I
+want this path to be portable to?"  By providing support for several
+answers to that question, the Filesystem Library alerts programmers of the need
+to ask it in the first place.
+<h2><a name="Abandoned_Designs">Abandoned Designs</a></h2>
+<h3>operations.hpp</h3>
+Dietmar Kühl's original dir_it design and implementation supported
+wide-character file and directory names. It was abandoned after extensive
+discussions among Library Working Group members failed to identify portable
+semantics for wide-character names on systems not providing native support. See
+FAQ.
+Previous iterations of the interface design used explicitly named functions providing a
+large number of convenience operations, with no compile-time or run-time
+options. There were so many function names that they were very confusing to use,
+and the interface was much larger. Any benefits seemed theoretical rather than
+real. 
+Designs based on compile time (rather than runtime) flag and option selection
+(via policy, enum, or int template parameters) became so complicated that they
+were abandoned, often after investing quite a bit of time and effort. The need
+to qualify attribute or option names with namespaces, even aliases, made use in
+template parameters ugly; that wasn't fully appreciated until actually writing
+real code.
+Yet another set of convenience functions ( for example, remove with
+permissive, prune, recurse, and other options, plus predicate, and possibly
+other, filtering features) were abandoned because the details became both
+complex and contentious.
+
+What is left is a toolkit of low-level operations from which the user can
+create more complex convenience operations, plus a very small number of
+convenience functions which were found to be useful enough to justify inclusion.
+
+<h3>path.hpp</h3>
+
+There were so many abandoned path designs, I've lost track. Policy-based
+class templates in several flavors, constructor supplied runtime policies,
+operation specific runtime policies, they were all considered, often
+implemented, and ultimately abandoned as far too complicated for any small
+benefits observed.
+
+Additional design considerations apply to <a href="i18n.html">
+Internationalization</a>. 
+
+<h3>error checking</h3>
+
+A number of designs for the error checking machinery were abandoned, some
+after experiments with implementations. Totally automatic error checking was
+attempted in particular. But automatic error checking tended to make the overall
+library design much more complicated.
+
+Some designs associated error checking mechanisms with paths.  Some with
+operations functions.  A policy-based error checking template design was
+partially implemented, then abandoned as too complicated for everyday
+script-like programs.
+
+The final design, which depends partially on explicit error checking function
+calls,  is much simpler and straightforward, although it does depend to
+some extent on programmer discipline.  But it should allow programmers who
+are concerned about portability to be reasonably sure that their programs will
+work correctly on their choice of target systems.
+
+<h2><a name="References">References</a></h2>
+
+<table border="0" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%">
+ <tr>
+ <td width="13%" valign="top">[<a name="IBM-01">IBM-01</a>]</td>
+ <td width="87%">IBM Corporation, z/OS V1R3.0 C/C++ Run-Time
+Library Reference, SA22-7821-02, 2001,
+<a href="http://www-1.ibm.com/servers/eserver/zseries/zos/bkserv/">
+ www-1.ibm.com/servers/eserver/zseries/zos/bkserv/</a></td>
+ </tr>
+ <tr>
+ <td width="13%" valign="top">[<a name="ISO-9660">ISO-9660</a>]</td>
+ <td width="87%">International Standards Organization, 1988</td>
+ </tr>
+ <tr>
+ <td width="13%" valign="top">[<a name="Kuhn">Kuhn</a>]</td>
+ <td width="87%">UTF-8 and Unicode FAQ for Unix/Linux,
+<a href="http://www.cl.cam.ac.uk/~mgk25/unicode.html">
+ www.cl.cam.ac.uk/~mgk25/unicode.html</a></td>
+ </tr>
+ <tr>
+ <td width="13%" valign="top">[<a name="MSDN">MSDN</a>] </td>
+ <td width="87%">Microsoft Platform SDK for Windows, Storage Start
+Page,
+<a href="http://msdn.microsoft.com/library/en-us/fileio/base/storage_start_page.asp">
+ msdn.microsoft.com/library/en-us/fileio/base/storage_start_page.asp</a></td>
+ </tr>
+ <tr>
+ <td width="13%" valign="top">[<a name="POSIX-01">POSIX-01</a>]</td>
+ <td width="87%">IEEE Std 1003.1-2001, ISO/IEC 9945:2002, and The Open Group Base Specifications, Issue 6. Also known as The
+ Single Unix® Specification, Version 3.
+ Available from each of the organizations involved in its creation. For
+ example, read online or download from
+ <a href="http://www.unix.org/single_unix_specification/">
+ www.unix.org/single_unix_specification/</a>. The ISO JTC1/SC22/WG15 - POSIX
+homepage is <a href="http://www.open-std.org/jtc1/sc22/WG15/">
+ www.open-std.org/jtc1/sc22/WG15/</a></td>
+ </tr>
+ <tr>
+ <td width="13%" valign="top">[<a name="URI">URI</a>]</td>
+ <td width="87%">RFC-2396, Uniform Resource Identifiers (URI): Generic
+Syntax, <a href="http://www.ietf.org/rfc/rfc2396.txt">
+ www.ietf.org/rfc/rfc2396.txt</a></td>
+ </tr>
+ <tr>
+ <td width="13%" valign="top">[<a name="UTF-16">UTF-16</a>]</td>
+ <td width="87%">Wikipedia, UTF-16,
+<a href="http://en.wikipedia.org/wiki/UTF-16">
+ en.wikipedia.org/wiki/UTF-16</a></td>
+ </tr>
+ <tr>
+ <td width="13%" valign="top">[<a name="Wulf-Shaw-73">Wulf-Shaw-73</a>]</td>
+ <td width="87%">William Wulf, Mary Shaw, Global
+Variable Considered Harmful, ACM SIGPLAN Notices, 8, 2, 1973, pp. 23-34</td>
+ </tr>
+</table>
+
+<hr>
+Revised
+02 August, 2005
+
+© Copyright Beman Dawes, 2002
+ 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>)
+
+</body>
+
+</html>
\ No newline at end of file

Added: sandbox/filesystem-v3/libs/filesystem/doc/faq.htm
==============================================================================
--- (empty file)
+++ sandbox/filesystem-v3/libs/filesystem/doc/faq.htm 2009-02-01 09:38:12 EST (Sun, 01 Feb 2009)
@@ -0,0 +1,150 @@
+<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/html/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">
+ Filesystem Library
+ </td>
+ </tr>
+</table>
+
+<table border="0" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" bgcolor="#D7EEFF" width="100%">
+ <tr>
+ <td>Boost Home   
+ Library Home   
+ Tutorial    <a href="reference.html">
+ Reference</a>   FAQ</td>
+ </tr>
+</table>
+
+<h1>
+Frequently Asked Questions</h1>
+Why base the generic-path string format on POSIX?
+[POSIX-01] 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.  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.)
+Why not use a full URI (Universal Resource Identifier) based path?
+URI's 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.
+Why isn't path a base class with derived directory_path and
+file_path classes?
+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.
+Why are fully specified paths called complete rather than 
+<a name="absolute">absolute</a>?
+To avoid long-held assumptions (what do you mean, "/foo" 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.
+Why not support a concept of specific kinds of file systems, such as posix_file_system or windows_file_system.
+Portability is one of the 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.
+Furthermore, concepts like "file system"
+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.
+Why not supply a 'handle' type, and let the file and directory operations
+traffic in it?
+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.    
+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.
+Why are the operations.hpp non-member functions so low-level?
+To provide a toolkit from which higher-level functionality can be created.
+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>.
+Isn't it inconsistent then to provide a few convenience functions?
+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.
+Why are there basic_directory_iterator<> overloads for operations.hpp
+predicate functions? Isn't two ways to do the same thing poor design?
+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.
+Why are library functions so picky about errors?
+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 globally shared resources, and thus subject to
+unexpected errors.
+Why are errors reported by exception rather than return code or error
+notification variable?
+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. Non-throwing versions of functions are provided where experience
+indicates the need.
+Why are attributes accessed via named functions rather than property maps?
+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 "read-only" turned out to be so
+system depend as to be disqualified as a "guaranteed presence" operation.)
+Why aren't <a name="wide-character_names">wide-character names</a> supported? Why not std::wstring or even
+a templated type?
+They are supported, starting with version 1.33. See
+Internationalization.
+Why isn't automatic name portability error detection provided?
+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. 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.
+Why are paths sometimes manipulated by member functions and sometimes by
+non-member functions?
+The design rule is that purely lexical operations are supplied as class
+basic_path member
+functions, while operations performed by the operating system are provided as
+free functions.
+<hr>
+Revised
+18 March, 2008
+© Copyright Beman Dawes, 2002
+ 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>
\ No newline at end of file

Added: sandbox/filesystem-v3/libs/filesystem/doc/index.htm
==============================================================================
--- (empty file)
+++ sandbox/filesystem-v3/libs/filesystem/doc/index.htm 2009-02-01 09:38:12 EST (Sun, 01 Feb 2009)
@@ -0,0 +1,816 @@
+<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 Home</title>
+<link rel="stylesheet" type="text/css" href="../../../doc/html/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">
+ Filesystem Library
+ </td>
+ </tr>
+</table>
+
+<table border="0" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" bgcolor="#D7EEFF" width="100%">
+ <tr>
+ <td>Boost Home   
+ Library Home    Tutorial    <a href="reference.html">
+ Reference</a>   FAQ</td>
+ </tr>
+</table>
+
+<table border="1" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" align="right">
+ <tr>
+ <td width="100%" bgcolor="#D7EEFF" align="center">
+ Contents</td>
+ </tr>
+ <tr>
+ <td width="100%" bgcolor="#E8F5FF">
+ Introduction 
+ Using the library 
+ Two-minute tutorial 
+ Cautions 
+ Example programs 
+ Implementation 
+ Macros 
+ Deprecated names and features 
+ Using only narrow character paths 
+ Building the object-library 
+     Notes for Cygwin users 
+ Acknowledgements 
+ Change history</td>
+ </tr>
+ <tr>
+ <td width="100%" bgcolor="#D7EEFF" align="center">
+ Other Documents</td>
+ </tr>
+ <tr>
+ <td width="100%" bgcolor="#E8F5FF">
+ Reference 
+ Library Design 
+ FAQ 
+ Portability Guide 
+ Do-list
+ </td>
+ </tr>
+</table>
+
+<h2><a name="Introduction">Introduction</a></h2>
+The Boost.Filesystem library provides portable facilities to query and
+manipulate paths, files, and directories.
+
+The motivation for the library is the need to perform portable script-like operations from within C++ programs. The intent is not to
+compete with Python, Perl, or shell languages, but rather to provide portable filesystem
+operations when C++ is already the language of choice. The <a href="design.htm">
+design</a> encourages, but does not require, safe and portable usage.
+
+Programs using the library are portable, both in the sense that
+the syntax of program code is portable, and the sense that the semantics or
+behavior of code is portable. The <a href="reference.html">generic path
+grammar</a> is another important aid to portability.
+
+Usage is safe in the sense that errors cannot be ignored since most functions throw C++
+exceptions when errors are detected. This is also convenient for users because
+it alleviates the need to explicitly check error
+return codes.
+
+A proposal,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1975.html">
+N1975</a>, to include Boost.Filesystem in Technical Report 2 has been accepted
+by the C++ Standards Committee. The Boost.Filesystem library will stay in
+alignment with the TR2 Filesystem proposal as it works its way through the TR2
+process. Note, however, that namespaces and header granularity differs between
+Boost.Filesystem and the TR2 proposal.
+
+The Boost.Filesystem library provides several  headers:
+
+<ul>
+ <li>Header <boost/filesystem.hpp> provides class 
+ basic_path, a portable mechanism for representing
+ paths in C++ programs. Typedefs path and 
+ wpath ease the most common usages of basic_path. Operational
+ functions provide useful query and maintenance operations on files and directories.
+ Class basic_directory_iterator with typdefs 
+ directory_iterator and wdirectory_iterator provide iteration over
+ the contents of directories. Convenience functions and classes combine lower-level functionality
+ in useful ways. 
+ </li>
+ <li>Header <boost/filesystem/fstream.hpp> provides the same components as the C++ Standard
+ Library's fstream header, except
+ that files are identified by basic_path objects rather that char *'s.</li>
+</ul>
+<h2><a name="Using">Using</a> the library</h2>
+Boost.Filesystem is implemented as a separately compiled library, so before
+using it you must install it in a location that can be found by your linker. See
+Building the object-library. 
+The library's example directory contains very simple
+scripts for building the example programs on various
+platforms. You can use these scripts to see what's needed to compile and link
+your own programs.
+<h2>Two-minute <a name="tutorial">tutorial</a></h2>
+(A
+<a href="http://beans.seartipy.com/2006/05/10/boost-filesystem-library-writing-portable-c-programs-to-acess-the-filesystem/">
+more elaborate tutorial</a> is also available from Tabrez Iqbal.)
+First some preliminaries:
+<blockquote>
+ <pre>#include "boost/filesystem.hpp" // includes all needed Boost.Filesystem declarations
+#include <iostream> // for std::cout
+using boost::filesystem; // for ease of tutorial presentation;
+ // a namespace alias is preferred practice in real code</pre>
+</blockquote>
+A class path object can be created:
+<blockquote>
+ <pre>path my_path( "some_dir/file.txt" );</pre>
+</blockquote>
+The string passed to the path constructor may be in a
+portable generic path format or an
+implementation-defined native operating system format. Access functions
+make my_path contents available to the underlying operating system API in an operating system dependent format,
+such as <code>"some_dir:file.txt"</code>, <code>"[some_dir]file.txt"</code>,
+<code>"some_dir/file.txt"</code>, or whatever is appropriate for the
+operating system. If class wpath is used instead of class path,
+translation between wide and narrow character paths is performed automatically
+if necessary for the operating system.
+Class path has conversion constructors from const char* and 
+const std:: string&, so that even though the Filesystem Library
+functions used in the following code snippet have const path& formal
+parameters, the user can just
+code C-style strings as actual arguments:
+<blockquote>
+ <pre>remove_all( "foobar" );
+create_directory( "foobar" );
+ofstream file( "foobar/cheeze" );
+file << "tastes good!\n";
+file.close();
+if ( !exists( "foobar/cheeze" ) )
+ std::cout << "Something is rotten in foobar\n";</pre>
+</blockquote>
+To make class path objects easy to use in expressions, operator/
+appends paths:
+<blockquote>
+ <pre>ifstream file1( arg_path / "foo/bar" );
+ifstream file2( arg_path / "foo" / "bar" );</pre>
+</blockquote>
+The expressions arg_path / "foo/bar" and arg_path / "foo"
+/ "bar" yield identical results.
+Paths can include references to the current directory, using "<code>.</code>"
+notation, and the parent directory, using "<code>..</code>"
+notation.
+Class basic_directory_iterator
+is an important component of the library. It provides an input iterator over the
+contents of a directory, with the value type being class basic_path.
+Typedefs directory_iterator and wdirectory_iterator are provided
+to cover the most common use cases.
+The following function, given a directory path and a file name, recursively
+searches the directory and its sub-directories for the file name, returning a
+bool, and if successful, the path to the file that was found.  The code
+below is extracted from a real program, slightly modified for clarity:
+<blockquote>
+ <pre>bool find_file( const path & dir_path, // in this directory,
+ const std::string & file_name, // search for this name,
+ path & path_found ) // placing path here if found
+{
+ if ( !exists( dir_path ) ) return false;
+ directory_iterator end_itr; // default construction yields past-the-end
+ for ( directory_iterator itr( dir_path );
+ itr != end_itr;
+ ++itr )
+ {
+ if ( is_directory(itr->status()) )
+ {
+ if ( find_file( itr->path(), file_name, path_found ) ) return true;
+ }
+ else if ( itr->leaf() == file_name ) // see below
+ {
+ path_found = itr->path();
+ return true;
+ }
+ }
+ return false;
+}</pre>
+</blockquote>
+The expression itr->path().leaf() == file_name, in the line commented //
+see below, calls the leaf() function on the path returned by
+calling the path() function of the directory_entry object pointed
+to by the iterator. leaf() returns a string which is a copy of the
+last (closest to the leaf, farthest from the root) file or directory name in the
+path object.
+In addition to leaf(), several other function names use the
+tree/root/branch/leaf metaphor.
+Notice that find_file() does not do explicit error checking, such as
+verifying that the dir_path argument really represents a directory.
+Boost.Filesystem functions throw
+exceptions if they do not complete successfully, so there is enough implicit
+error checking that this application doesn't need to supply additional error
+checking code unless desired. Several Boost.Filesystem functions have non-throwing
+versions, to ease use cases where exceptions would not be appropriate.
+<blockquote>
+Note: Recursive
+directory iteration was added as a convenience function after the above tutorial code
+was written, so nowadays you
+don't have to actually code the recursion yourself.
+</blockquote>
+<h2><a name="Cautions">Cautions</a></h2>
+After reading the tutorial you can dive right into simple,
+script-like programs using the Filesystem Library! Before doing any serious
+work, however, there a few cautions to be aware of:
+<h4>Effects and Postconditions not guaranteed in the presence of race-conditions</h4>
+Filesystem function specifications follow the C++ Standard Library form, specifying behavior in terms of
+effects and postconditions. If
+a race-condition exists, a function's
+postconditions may no longer be true by the time the function returns to the
+caller.
+<blockquote>
+Explanation: The state of files and directories is often
+globally shared, and thus may be changed unexpectedly by other threads,
+processes, or even other computers having network access to the filesystem. As an
+example of the difficulties this can cause, note that the following asserts
+may fail:
+<blockquote>
+<code>assert( exists( "foo" ) == exists( "foo" ) );  //
+(1) 
+ 
+remove_all( "foo" ); 
+assert( !exists( "foo" ) );  // (2) 
+ 
+assert( is_directory( "foo" ) == is_directory( "foo" ) ); //
+(3)</code>
+</blockquote>
+(1) will fail if a non-existent "foo" comes into existence, or an
+existent "foo" is removed, between the first and second call to exists().
+This could happen if, during the execution of the example code, another thread,
+process, or computer is also performing operations in the same directory.
+(2) will fail if between the call to remove_all() and the call to
+exists() a new file or directory named "foo" is created by another
+thread, process, or computer.
+(3) will fail if another thread, process, or computer removes an
+existing file "foo" and then creates a directory named "foo", between the
+example code's two calls to is_directory().
+</blockquote>
+<h4>May throw exceptions</h4>
+Unless otherwise specified, Boost.Filesystem functions throw 
+basic_filesystem_error
+exceptions if they cannot successfully complete their operational
+specifications. Also, implementations may use C++ Standard Library functions,
+which may throw std::bad_alloc. These exceptions may be thrown even
+though the error condition leading to the exception is not explicitly specified
+in the function's "Throws" paragraph.
+All exceptions thrown by the Filesystem
+Library are implemented by calling <a href="../../utility/throw_exception.html">
+boost::throw_exception()</a>. Thus exact behavior may differ depending on
+BOOST_NO_EXCEPTIONS at the time the filesystem source files are compiled.
+Non-throwing versions are provided of several functions that are often used
+in contexts where error codes may be the preferred way to report an error.
+<h2><a name="Examples">Example programs</a></h2>
+<h3>simple_ls.cpp</h3>
+The example program simple_ls.cpp is
+given a path as a command line argument. Since the command line argument may be
+a relative path, the complete path is determined so that messages displayed
+can be more precise.
+The program checks to see if the path exists; if not a message is printed.
+If the path identifies a directory, the directory is iterated through,
+printing the name of the entries found, and an indication if they are
+directories. A count of directories and files is updated, and then printed after
+the iteration is complete.
+If the path is for a file, a message indicating that is printed.
+Try compiling and executing simple_ls.cpp
+to see how it works on your system. Try various path arguments to see what
+happens.
+<h3>file_size.cpp</h3>
+This example program prints the file's size if it is a regular file.
+<h3>Other examples</h3>
+The programs used to generate the Boost regression test status tables use the
+Filesystem Library extensively.  See:
+<ul>
+ <li>process_jam_log.cpp</li>
+ <li>compiler_status.cpp</li>
+</ul>
+Test programs are sometimes useful in understanding a library, as they
+illustrate what the developer expected to work and not work. See:
+<ul>
+ <li>wide_test.cpp</li>
+ <li>path_test.cpp</li>
+ <li>operations_test.cpp</li>
+ <li>fstream_test.cpp</li>
+</ul>
+<h2><a name="Implementation">Implementation</a></h2>
+The current implementation supports operating systems which provide
+either the POSIX or Windows API.
+The library is in regular use on Apple OS X, HP-UX, IBM AIX, Linux,
+Microsoft Windows, SGI IRIX, and Sun Solaris operating systems using a variety
+of compilers.
+<h2><a name="Macros">Macros</a></h2>
+Users may defined the following macros if desired. Sensible defaults are
+provided, so users can ignore these macros unless they have special needs.
+<table border="1" cellpadding="5" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111">
+ <tr>
+ <td>Macro Name</td>
+ <td>Default</td>
+ <td>Effect if defined</td>
+ </tr>
+ <tr>
+ <td valign="top"><code>BOOST_WINDOWS_API</code></td>
+ <td valign="top">Defined if Windows is detected by Boost.System's automatic configuration
+ code, otherwise not defined.</td>
+ <td valign="top">Implementation uses the Microsoft Windows native
+ application program interface (API).</td>
+ </tr>
+ <tr>
+ <td valign="top"><code>BOOST_POSIX_API</code></td>
+ <td valign="top">Defined if Windows is not detected by Boost.System's automatic configuration
+ code.</td>
+ <td valign="top">Implementation uses the POSIX native
+ application program interface (API).</td>
+ </tr>
+ <tr>
+ <td valign="top"><code>BOOST_FILESYSTEM_DYN_LINK</code></td>
+ <td valign="top">Defined if <code>BOOST_ALL_DYN_LINK</code> is defined,
+ otherwise not defined.</td>
+ <td valign="top">Boost.System library is dynamically linked. If not defined,
+ static linking is assumed.</td>
+ </tr>
+ <tr>
+ <td valign="top"><code>BOOST_FILESYSTEM_NO_LIB</code></td>
+ <td valign="top">Defined if <code>BOOST_ALL_NO_LIB</code> is defined,
+ otherwise not defined.</td>
+ <td valign="top">Boost.System library does not use the Boost auto-link
+ facility.</td>
+ </tr>
+ <tr>
+ <td valign="top"><code>BOOST_FILESYSTEM_NARROW_ONLY</code></td>
+ <td valign="top">Not defined.</td>
+ <td valign="top">Removes features that require wchar_t support.</td>
+ </tr>
+ <tr>
+ <td valign="top"><code>BOOST_FILESYSTEM_NO_DEPRECATED</code></td>
+ <td valign="top">Not defined.</td>
+ <td valign="top">Deprecated features are excluded.</td>
+ </tr>
+</table>
+<h2><a name="Deprecated-names">Deprecated names</a> and features</h2>
+As the library evolves over time, names sometimes
+change or features are removed. To ease transition, Boost.Filesystem deprecates
+the old names and features, but continues to provide them unless macro <code>
+BOOST_FILESYSTEM_NO_DEPRECATED</code> is defined.
+<table border="1" cellpadding="5" cellspacing="1" style="border-collapse: collapse" bordercolor="#111111">
+ <tr>
+ <td style="font-size: 10pt">
+ Component</td>
+ <td style="font-size: 10pt">
+ Old name, now deprecated</td>
+ <td style="font-size: 10pt">
+ New name</td>
+ </tr>
+ <tr>
+ <td style="font-size: 10pt" valign="top"><code>basic_path</code></td>
+ <td style="font-size: 10pt"><code>leaf()</code></td>
+ <td style="font-size: 10pt"><code>filename()</code></td>
+ </tr>
+ <tr>
+ <td style="font-size: 10pt" valign="top"><code>basic_path</code></td>
+ <td style="font-size: 10pt"><code>branch_path()</code></td>
+ <td style="font-size: 10pt"><code>parent_path()</code></td>
+ </tr>
+ <tr>
+ <td style="font-size: 10pt" valign="top"><code>basic_path</code></td>
+ <td style="font-size: 10pt"><code>has_leaf()</code></td>
+ <td style="font-size: 10pt"><code>has_filename()</code></td>
+ </tr>
+ <tr>
+ <td style="font-size: 10pt" valign="top"><code>basic_path</code></td>
+ <td style="font-size: 10pt"><code>has_branch_path()</code></td>
+ <td style="font-size: 10pt"><code>has_parent_path()</code></td>
+ </tr>
+ <tr>
+ <td style="font-size: 10pt" valign="top">
+ <code>basic_path</code></td>
+ <td style="font-size: 10pt">
+ <code>remove_leaf()</code></td>
+ <td style="font-size: 10pt">
+ <code>remove_filename()</code></td>
+ </tr>
+ <tr>
+ <td style="font-size: 10pt" valign="top">
+ <code>basic_path</code></td>
+ <td style="font-size: 10pt">
+ <code>basic_path( const string_type & str, 
+  name_check )</code></td>
+ <td style="font-size: 10pt">
+ <code>feature removed</code></td>
+ </tr>
+ <tr>
+ <td style="font-size: 10pt" valign="top">
+ <code>basic_path</code></td>
+ <td style="font-size: 10pt">
+ <code>basic_path( const string_type::value_type * s, 
+  name_check )</code></td>
+ <td style="font-size: 10pt">
+ <code>feature removed</code></td>
+ </tr>
+ <tr>
+ <td style="font-size: 10pt" valign="top">
+ <code>basic_path</code></td>
+ <td style="font-size: 10pt">
+ <code>native_file_string()</code></td>
+ <td style="font-size: 10pt">
+ <code>file_string()</code></td>
+ </tr>
+ <tr>
+ <td style="font-size: 10pt" valign="top">
+ <code>basic_path</code></td>
+ <td style="font-size: 10pt">
+ <code>native_directory_string()</code></td>
+ <td style="font-size: 10pt">
+ <code>directory_string()</code></td>
+ </tr>
+ <tr>
+ <td style="font-size: 10pt" valign="top">
+ <code>basic_path</code></td>
+ <td style="font-size: 10pt">
+ <code>default_name_check_writable()</code></td>
+ <td style="font-size: 10pt">
+ <code>feature removed</code></td>
+ </tr>
+ <tr>
+ <td style="font-size: 10pt" valign="top">
+ <code>basic_path</code></td>
+ <td style="font-size: 10pt">
+ <code>default_name_check( name_check )</code></td>
+ <td style="font-size: 10pt">
+ <code>feature removed</code></td>
+ </tr>
+ <tr>
+ <td style="font-size: 10pt" valign="top">
+ <code>basic_path</code></td>
+ <td style="font-size: 10pt">
+ <code>default_name_check()</code></td>
+ <td style="font-size: 10pt">
+ <code>feature removed</code></td>
+ </tr>
+ <tr>
+ <td style="font-size: 10pt" valign="top">
+ <code>basic_path</code></td>
+ <td style="font-size: 10pt">
+ <code>canonize()</code></td>
+ <td style="font-size: 10pt">
+ <code>feature removed</code></td>
+ </tr>
+ <tr>
+ <td style="font-size: 10pt" valign="top">
+ <code>basic_path</code></td>
+ <td style="font-size: 10pt">
+ <code>normalize()</code></td>
+ <td style="font-size: 10pt">
+ <code>feature removed</code></td>
+ </tr>
+ <tr>
+ <td style="font-size: 10pt" valign="top">
+ <code>operations.hpp</code></td>
+ <td style="font-size: 10pt">
+ <code>is_regular( file_status f )</code></td>
+ <td style="font-size: 10pt">
+ <code>is_regular_file( file_status f )</code></td>
+ </tr>
+ <tr>
+ <td style="font-size: 10pt" valign="top">
+ <code>operations.hpp</code></td>
+ <td style="font-size: 10pt">
+ <code>symbolic_link_exists( const path & ph )</code></td>
+ <td style="font-size: 10pt">
+ <code>feature removed</code></td>
+ </tr>
+ <tr>
+ <td style="font-size: 10pt" valign="top">
+ <code>basic_directory_status</code></td>
+ <td style="font-size: 10pt">
+ <code>filename()</code></td>
+ <td style="font-size: 10pt">
+ <code>feature removed, use path().filename() instead</code></td>
+ </tr>
+ <tr>
+ <td style="font-size: 10pt" valign="top">
+ <code>basic_directory_status</code></td>
+ <td style="font-size: 10pt">
+ <code>leaf()</code></td>
+ <td style="font-size: 10pt">
+ <code>feature removed, use path().filename() instead</code></td>
+ </tr>
+ <tr>
+ <td style="font-size: 10pt" valign="top">
+ <code>basic_directory_status</code></td>
+ <td style="font-size: 10pt">
+ <code>string()</code></td>
+ <td style="font-size: 10pt">
+ <code>feature removed, use path().string() instead</code></td>
+ </tr>
+</table>
+<h2><a name="narrow-only">Restricting library to narrow character paths</a></h2>
+Compilers or standard libraries which do not support wide characters (wchar_t)
+or wide character strings (std::wstring) are detected automatically, and cause
+the library to compile code that is restricted to narrow character paths
+(boost::filesystem::path). Users can force this restriction by defining the
+macro BOOST_FILESYSTEM_NARROW_ONLY. That may be useful for dealing with legacy
+compilers or operating systems.
+<h2><a name="Building">Building</a> the object-library</h2>
+The object-library will be built automatically if you are using the Boost
+build system. See
+Getting Started. It can also be
+built manually using a Jamfile
+supplied in directory libs/filesystem/build, or the user can construct an IDE
+project or make file which includes the object-library source files.
+The object-library source files are
+supplied in directory libs/filesystem/src. These source files implement the
+library for POSIX or Windows compatible operating systems; no implementation is
+supplied for other operating systems. Note that many operating systems not
+normally thought of as POSIX systems, such as mainframe legacy
+operating systems or embedded operating systems, support POSIX compatible file
+systems which will work with the Filesystem Library.
+The object-library can be built for static or dynamic (shared/dll) linking.
+This is controlled by the BOOST_ALL_DYN_LINK or BOOST_FILESYSTEM_DYN_LINK
+macros. See the <a href="http://www.boost.org/development/separate_compilation.html">Separate
+Compilation</a> page for a description of the techniques used.
+<h3>Note for <a name="Cgywin">Cygwin</a> users</h3>
+The library's implementation code automatically detects the current platform,
+and compiles the POSIX or Windows implementation code accordingly. Automatic
+platform detection during object library compilation can be overridden by
+defining either BOOST_POSIX_API or BOOST_WINDOWS_API macros. With the exception of the Cygwin
+environment, there is usually no reason to define these macros, as the
+software development kits supplied with most compilers only support a single
+platform.
+The Cygwin package of tools supports
+traditional Windows usage, but also provides an emulation layer and other tools
+which can be used to make Windows act as Linux (and thus POSIX), and provide the
+Linux look-and-feel. GCC is usually the compiler of choice in this environment,
+as it can be installed via the Cygwin install process. Other compilers can also
+use the Cygwin emulation of POSIX, at least in theory.
+Those wishing to use the Cygwin POSIX emulation layer should define the
+BOOST_POSIX_API macro when compiling bother user programs and the
+Boost.Filesystem's object-library.
+<h2><a name="Acknowledgements">Acknowledgements</a></h2>
+The Filesystem Library was designed and implemented by Beman Dawes. The
+original directory_iterator and filesystem_error classes were
+based on prior work from Dietmar Kuehl, as modified by Jan Langer. Thomas Witt
+was a particular help in later stages of initial development. Peter Dimov and
+Rob Stewart made many useful suggestions and comments over a long period of
+time. Howard Hinnant helped with internationalization issues.
+
+Key design requirements and
+design realities were developed during
+extensive discussions on the Boost mailing list, followed by comments on the
+initial implementation. Numerous helpful comments were then received during the
+Formal Review.Participants included
+Aaron Brashears,
+Alan Bellingham,
+Aleksey Gurtovoy,
+Alex Rosenberg,
+Alisdair Meredith,
+Andy Glew,
+Anthony Williams,
+Baptiste Lepilleur,
+Beman Dawes,
+Bill Kempf,
+Bill Seymour,
+Carl Daniel,
+Chris Little,
+Chuck Allison,
+Craig Henderson,
+Dan Nuffer,
+Dan'l Miller,
+Daniel Frey,
+Darin Adler,
+David Abrahams,
+David Held,
+Davlet Panech,
+Dietmar Kuehl,
+Douglas Gregor,
+Dylan Nicholson,
+Ed Brey,
+Eric Jensen,
+Eric Woodruff,
+Fedder Skovgaard,
+Gary Powell,
+Gennaro Prota,
+Geoff Leyland,
+George Heintzelman,
+Giovanni Bajo,
+Glen Knowles,
+Hillel Sims,
+Howard Hinnant,
+Jaap Suter,
+James Dennett,
+Jan Langer,
+Jani Kajala,
+Jason Stewart,
+Jeff Garland,
+Jens Maurer,
+Jesse Jones,
+Jim Hyslop,
+Joel de Guzman,
+Joel Young,
+John Levon,
+John Maddock,
+John Williston,
+Jonathan Caves,
+Jonathan Biggar,
+Jurko,
+Justus Schwartz,
+Keith Burton,
+Ken Hagen,
+Kostya Altukhov,
+Mark Rodgers,
+Martin Schuerch,
+Matt Austern,
+Matthias Troyer,
+Mattias Flodin,
+Michiel Salters,
+Mickael Pointier,
+Misha Bergal,
+Neal Becker,
+Noel Yap,
+Parksie,
+Patrick Hartling, Pavel Vozenilek,
+Pete Becker,
+Peter Dimov,
+Rainer Deyke,
+Rene Rivera,
+Rob Lievaart,
+Rob Stewart,
+Ron Garcia,
+Ross Smith,
+Sashan,
+Steve Robbins,
+Thomas Witt,
+Tom Harris,
+Toon Knapen,
+Victor Wagner,
+Vincent Finn,
+Vladimir Prus, and
+Yitzhak Sapir
+
+A lengthy discussion on the C++ committee's library reflector illuminated the "illusion
+of portability" problem, particularly in postings by PJ Plauger and Pete Becker.
+
+Walter Landry provided much help illuminating symbolic link use cases for
+version 1.31.0.
+
+<h3>Version 1.34 (i18n) acknowledgements</h3>
+
+So many people have contributed comments and bug reports that it isn't any
+longer possible to acknowledge them individually. That said, Peter Dimov and Rob
+Stewart need to be specially thanked for their many constructive criticisms and
+suggestions. Terence
+Wilson and Chris Frey contributed timing programs which helped illuminate
+performance issues.
+
+<h2><a name="Change-history">Change history</a></h2>
+
+<h3>Version 1.37.0</h3>
+
+<ul>
+ <li>Doc fixes: Update release history, add tables of macros and deprecated
+ names.</li>
+ <li>Bug fix: convenience.hpp didn't fully apply BOOST_FILESYSTEM_NO_DEPRECATED
+ to name changes.</li>
+ <li>Bug fix: Ticket #1972 'remove' fixes.</li>
+ <li>Bug fix: Restore deprecated basic_directory_entry names inadvertently
+ removed.</li>
+ <li>Bug fix: Provide deprecated functions has_branch_path and has_leaf,
+ inadvertently omitted from 1.36.0</li>
+ <li>Add workarounds for Codegear/Borland C++ Builder 2009.</li>
+</ul>
+
+<h3>Version 1.36.0 - August 14th, 2008</h3>
+
+<ul>
+ <li>Added stem(), extension(), and replace_extension() member functions to
+ basic_path, based on the basename(), extension(), and change_extension()
+ functions from convenience.hpp.</li>
+ <li>Changed path.hpp function names:<ul>
+ <li>leaf() -> filename().</li>
+ <li>has_leaf() -> has_filename().</li>
+ <li>branch_path() -> parent_path().</li>
+ <li>has_branch_path() -> has_parent_path().</li>
+ <li>remove_leaf() -> remove_filename().</li>
+ </ul>
+ </li>
+ <li>Changed operations.hpp function names:<ul>
+ <li>is_regular() -> is_regular_file().</li>
+ </ul>
+ </li>
+ <li>Bug fix: Add path.cpp #include <cwchar></li>
+ <li>Cleared path.hpp gcc shadow warnings.</li>
+</ul>
+
+<h3>Version 1.35.0 - March 29th, 2008</h3>
+
+<ul>
+ <li>Diagnostics moved to the separate <a href="../../system/doc/index.html">
+ Boost.System</a> library.</li>
+ <li>current_path() function added to set the current directory path.</li>
+ <li>Test coverage extended.</li>
+ <li>A few minor implementation fixes.</li>
+</ul>
+
+<h3>Version 1.34.1 - July 24th, 2007</h3>
+
+<h3>Version 1.34.0 - May 12th, 2007</h3>
+
+<ul>
+ <li>Internationalization, provided by
+ class templates basic_path, basic_filesystem_error, and 
+ basic_directory_iterator.</li>
+ <li>Simplification of the path interface,
+ including elimination of distinction between native and generic formats,
+ and separation of name checking functionality from general path functionality.</li>
+ <li>Rationalization of predicate
+ function design, including the addition of several new functions.</li>
+ <li>Preservation of existing user code whenever
+ possible. Deprecated features (symbolic_link_exists(), etc.) remain
+ available for legacy code.</li>
+ <li>Clearer specification, by reference to [POSIX-01],
+ the ISO/IEEE Single Unix Standard, with provisions for Windows and other
+ operating systems.</li>
+ <li>New functions status,
+ symlink_status,
+ is_file,
+ is_symlink,
+ create_hard_link,
+ create_symlink, path member and non-member swap, path inserter, path
+ extractor, additional path relational and "/" operator overloads, additional
+ path member template functions taking iterator arguments.</li>
+ <li>More efficient operations when iterating over directories.</li>
+ <li>Separation within the implementation of the distinction between the native
+ operating system path syntax and API. This is important for CYGWIN users
+ because it allows them to build for either the Windows or POSIX API's.</li>
+ <li>Numerous small implementation fixes.</li>
+</ul>
+
+<h3>Version 1.33.0 - August 11th, 2005</h3>
+
+<ul>
+ <li>Some small implementation fixes.</li>
+</ul>
+
+<h3>Version 1.32.0 - November 19th, 2004</h3>
+
+<ul>
+ <li>file_size() function added.</li>
+ <li>Class path relational operators added.</li>
+ <li>equivalent() function added.</li>
+ <li>create_directory() no longer
+ throws if the directory already exists. A bool is returned, indicating that
+ the directory did not preexist. Similar changes made to
+ create_directories().</li>
+ <li>Docs added for users wishing Cygwin/POSIX behavior
+ on Windows.</li>
+ <li>For POSIX, Large File Support (LSF) is enabled if available, such as on
+ Linux.</li>
+ <li>current_path() and
+ initial_path() on POSIX now handle
+ very long paths correctly.</li>
+</ul>
+
+<h3>Version 1.31.0 - January 26th, 2004</h3>
+
+<ul>
+ <li>The object library can now be built for either
+ static or dynamic (shared/dll) linking. </li>
+ <li>Several added functions, including improved checking for directory and
+ file name portability. See <a href="portability_guide.htm#name_checkÃ‚Â_functions">
+ Name check functions</a>.</li>
+ <li>Separation of canonical form and normalized form and a new path member
+ function normalize(). This changes behavior,
+ in that canonical form is now different, but eliminates a subtle
+ bug when symbolic links to
+ directories are present.</li>
+</ul>
+
+<h3>  
+Version 1.30.0 - March 19th, 2003</h3>
+<ul>
+ <li>Initial official Boost version.</li>
+</ul>
+
+<hr>
+Revised
+28 October, 2008
+
+© Copyright Beman Dawes, 2002-2005
+ 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>
+
+</body>
+
+</html>
\ No newline at end of file

Added: sandbox/filesystem-v3/libs/filesystem/doc/portability_guide.htm
==============================================================================
--- (empty file)
+++ sandbox/filesystem-v3/libs/filesystem/doc/portability_guide.htm 2009-02-01 09:38:12 EST (Sun, 01 Feb 2009)
@@ -0,0 +1,226 @@
+<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>Portability Guide</title>
+<link rel="stylesheet" type="text/css" href="../../../doc/html/minimal.css">
+</head>
+
+<body bgcolor="#FFFFFF">
+
+<h1>
+<img border="0" src="../../../boost.png" align="center" width="277" height="86">Path
+Name Portability
+Guide</h1>
+
+
+Introduction 
+name_check functions 
+File and directory name recommendations
+<h2><a name="Introduction">Introduction</a></h2>
+Like any other C++ program which performs I/O operations, there is no
+guarantee that a program using Boost.Filesystem will be portable between
+operating systems. Critical aspects of I/O such as how the operating system
+interprets paths are unspecified by the C and C++ Standards.
+It is not possible to know if a file or directory name will be
+valid (and thus portable) for an unknown operating system. There is always the possibility that an operating system could use
+names which are unusual (numbers less than 4096, for example) or very
+limited in size (maximum of six character names, for example). In other words,
+portability is never absolute; it is always relative to specific operating
+systems or
+file systems.
+It is possible, however, to know in advance if a directory or file name is likely to be valid for a particular
+operating system. It is also possible to construct names which are
+likely to be portable to a large number of modern and legacy operating systems.
+
+Almost all modern operating systems support multiple file systems. At the
+minimum, they support a native file system plus a CD-ROM file system (Generally
+ISO-9669, often with Juliet extensions).
+
+Each file system
+may have its own naming rules. For example, modern versions of Windows support NTFS, FAT, FAT32, and ISO-9660 file systems, among others, and the naming rules
+for those file systems differ. Each file system may also have
+differing rules for overall path validity, such as a maximum length or number of
+sub-directories. Some legacy systems have different rules for directory names
+versus regular file names.
+
+As a result, Boost.Filesystem's name_check functions
+cannot guarantee directory and file name portability. Rather, they are intended to
+give the programmer a "fighting chance" to achieve portability by early
+detection of common naming problems.
+
+<h2><a name="name_check_functions">name_check functions</a></h2>
+
+A name_check function
+returns true if its argument is valid as a directory and regular file name for a
+particular operating or file system. A number of these functions are provided.
+
+The portable_name function is of particular
+interest because it has been carefully designed to provide wide
+portability yet not overly restrict expressiveness.
+
+<table border="1" cellpadding="5" cellspacing="0">
+ <tr>
+ <td align="center" colspan="2">Library Supplied name_check Functions</td>
+ </tr>
+ <tr>
+ <td align="center">Function</td>
+ <td align="center">Description</td>
+ </tr>
+ <tr>
+ <td align="left" valign="top"><code><a name="portable_posix_name">portable_posix_name</a>(const
+ std::string& name)</code></td>
+ <td>Returns: true if <code>!name.empty() && name</code> contains only the characters
+ specified in Portable Filename Character Set rules as defined in by
+ POSIX (www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap03.html). 
+ The allowed characters are <code>0-9</code>, <code>a-z</code>, <code>A-Z</code>,
+ <code>'.'</code>, <code>'_'</code>, and <code>'-'</code>.Use:
+ applications which must be portable to any POSIX system.</td>
+ </tr>
+ <tr>
+ <td align="left" valign="top"><code><a name="windows_name">windows_name</a>(const
+ std::string& name)</code></td>
+ <td>Returns:  true if <code>!name.empty() && name</code> contains
+ only the characters specified by the Windows platform SDK as valid
+ regardless of the file system <code>&& (name</code> is <code>"."</code> or
+ <code>".."</code>  or does not end with a trailing space or period<code>)</code>. 
+ The allowed characters are anything except <code>0x0-0x1F</code>, <code>'<'</code>,
+ <code>'>'</code>, <code>':'</code>, <code>'"'</code>, <code>'/'</code>,
+ <code>'\'</code>, and <code>'|'</code>.
+ Use: applications which must be portable to Windows.
+ Note: Reserved device names are not valid as file names, but are
+ not being detected because they are still valid as a path. Specifically,
+ CON, PRN, AUX, CLOCK$, NUL, COM[1-9], LPT[1-9], and these names followed by
+ an extension (for example, NUL.tx7).</td>
+ </tr>
+ <tr>
+ <td align="left" valign="top"><code><a name="portable_name">portable_name</a>(const
+ std::string& name)</code></td>
+ <td>Returns: <code> windows_name(name) && portable_posix_name(name)
+ && (name</code> is <code>"."</code> or <code>".."</code>, and the first character not a period or hyphen<code>)</code>.Use: applications which must be portable to a wide variety of
+ modern operating systems, large and small, and to some legacy O/S's. The
+ first character not a period or hyphen restriction is a requirement of
+ several older operating systems.</td>
+ </tr>
+ <tr>
+ <td align="left" valign="top"><code><a name="portable_directory_name">
+ portable_directory_name</a>(const std::string& name)</code></td>
+ <td>Returns: <code>portable_name(name) && (name</code> is <code>"."</code>
+ or <code>".."</code>  or contains no periods<code>)</code>.Use: applications
+ which must be portable to a wide variety of platforms, including OpenVMS.</td>
+ </tr>
+ <tr>
+ <td align="left" valign="top"><code><a name="portable_file_name">
+ portable_file_name</a>(const std::string& name)</code></td>
+ <td>Returns: <code>portable_name(name) && </code>any period is followed by one to three additional
+ non-period characters.Use:
+ applications which must be portable to a wide variety of platforms,
+ including OpenVMS and other systems which have a concept of "file extension"
+ but limit its length.</td>
+ </tr>
+ <tr>
+ <td align="left" valign="top"><code><a name="native">native</a>(const
+ std::string& name)</code></td>
+ <td>Returns: Implementation defined. Returns 
+ true for names considered valid by the operating system's native file
+ systems.Note: May return true for some names not considered valid
+ by the operating system under all conditions (particularly on operating systems which support
+ multiple file systems.)</td>
+ </tr>
+</table>
+
+<h2>File and directory name <a name="recommendations">recommendations</a></h2>
+
+<table border="1" cellpadding="5" cellspacing="0">
+
+ <tr>
+ <td align="center" valign="top">Recommendation</td>
+ <td align="center" valign="top">Rationale</td>
+ </tr>
+ <tr>
+ <td valign="top">Limit file and directory names to the characters A-Z, a-z, 0-9, period, hyphen, and
+ underscore.Use any of the "portable_" <a href="#name_check_functions">
+ name check functions</a> to enforce this recommendation.</td>
+ <td valign="top">These are the characters specified by the POSIX standard for portable directory and
+ file names, and are also valid for Windows, Mac, and many other modern file systems.</td>
+ </tr>
+ <tr>
+ <td valign="top">Do not use a period or hyphen as the first
+ character of a name. Do not use period as the last character of a name.
+ Use portable_name,
+ portable_directory_name, or
+ portable_file_name to enforce this
+ recommendation.</td>
+ <td valign="top">Some operating systems treat have special rules for the
+ first character of names. POSIX, for example. Windows does not permit period
+ as the last character.</td>
+ </tr>
+ <tr>
+ <td valign="top">Do not use periods in directory names.Use
+ portable_directory_name to enforce
+ this recommendation.</td>
+ <td valign="top">Requirement for ISO-9660 without Juliet extensions, OpenVMS filesystem, and other legacy systems.</td>
+ </tr>
+ <tr>
+ <td valign="top">Do not use more that one period in a file name, and limit
+ the portion after the period to three characters.Use
+ portable_file_name to enforce this
+ recommendation.</td>
+ <td valign="top">Requirement for ISO-9660 level 1, OpenVMS filesystem, and
+ other legacy systems. </td>
+ </tr>
+ <tr>
+ <td valign="top">Do not assume names are case sensitive. For example, do not expected a directory to be
+ able to hold separate elements named "Foo" and "foo". </td>
+ <td valign="top">Some file systems are case insensitive.  For example, Windows
+ NTFS is case preserving in the way it stores names, but case insensitive in
+ searching for names (unless running under the POSIX sub-system, it which
+ case it does case sensitive searches). </td>
+ </tr>
+ <tr>
+ <td valign="top">Do not assume names are case insensitive.  For example, do not expect a file
+ created with the name of "Foo" to be opened successfully with the name of "foo".</td>
+ <td valign="top">Some file systems are case sensitive.  For example, POSIX.</td>
+ </tr>
+ <tr>
+ <td valign="top">Don't use hyphens in names.</td>
+ <td valign="top">ISO-9660 level 1, and possibly some legacy systems, do not permit
+ hyphens.</td>
+ </tr>
+ <tr>
+ <td valign="top">Limit the length of the string returned by path::string() to
+ 255 characters. 
+ Note that ISO 9660 has an explicit directory tree depth limit of 8, although
+ this depth limit is removed by the Juliet extensions.</td>
+ <td valign="top">Some operating systems place limits on the total path length.  For example,
+ Windows 2000 limits paths to 260 characters total length.</td>
+ </tr>
+ <tr>
+ <td valign="top">Limit the length of any one name in a path.  Pick the specific limit according to
+ the operating systems and or file systems you wish portability to: 
+    Not a concern::  POSIX, Windows, MAC OS X. 
+    31 characters: Classic Mac OS 
+   8 characters + period + 3 characters: ISO 9660 level 1 
+   32 characters: ISO 9660 level 2 and 3 
+   128 characters (64 if Unicode): ISO 9660 with Juliet extensions</td>
+ <td valign="top">Limiting name length can markedly reduce the expressiveness of file names, yet placing
+ only very high limits on lengths inhibits widest portability.</td>
+ </tr>
+</table>
+
+<hr>
+Revised
+11 January, 2009
+
+© Copyright Beman Dawes, 2002, 2003
+ 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>)
+
+</body>
+
+</html>
\ No newline at end of file

Modified: sandbox/filesystem-v3/libs/filesystem/doc/v3_design.html
==============================================================================
--- sandbox/filesystem-v3/libs/filesystem/doc/v3_design.html (original)
+++ sandbox/filesystem-v3/libs/filesystem/doc/v3_design.html 2009-02-01 09:38:12 EST (Sun, 01 Feb 2009)
@@ -5,7 +5,7 @@
<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 Home</title>
+<title>Filesystem V3 Introduction</title>
<link rel="stylesheet" type="text/css" href="minimal.css">
</head>

@@ -17,7 +17,7 @@
<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">
- Filesystem Library V3 Prototype Design
+ Boost.Filesystem Version 3 
 </td>
 </tr>
</table>
@@ -43,6 +43,7 @@
 <a href="#Details">Details</a> 
 <a href="#Other-changes">Other changes</a> 
 <a href="#Prototype">Prototype</a> 
+ Trying the prototype 
 <a href="#Acknowledgements">Acknowledgements</a></td>
 </tr>
 <tr>
@@ -58,7 +59,7 @@
<h2><a name="Introduction">Introduction</a></h2>

During the review of Boost.Filesystem.V2 (Internationalization), Peter Dimov
-suggested that the class basic_path template was unwieldy, and that a single
+suggested that the basic_path class template was unwieldy, and that a single
path type that accommodated multiple character types and encodings would be more
flexible. Although I wasn't willing to stop development at that time to
explore how this idea might be implemented, or to break from the pattern for
@@ -173,13 +174,12 @@
Additional filesystem operations:

<ul>
- <li>copy_any() added.</li>
- <li>copy_directory() added.</li>
- <li>copy_symlink() added.</li>
- <li>create_symlink() now available on Windows if supported (i.e. Vista and
- later).</li>
- <li>create_directory_symlink() added.</li>
- <li>read_symlink() added.</li>
+ <li>copy_directory().</li>
+ <li>copy_symlink(). On Windows, requires Vista or later.</li>
+ <li>copy().</li>
+ <li>create_symlink().  On Windows, requires Vista or later.</li>
+ <li>create_directory_symlink().  On Windows, requires Vista or later.</li>
+ <li>read_symlink().  Not supported on Windows.</li>
</ul>

<h2><a name="Prototype">Prototype</a></h2>
@@ -187,14 +187,31 @@
Currently incomplete. Not thoroughly tested. Should not be used for
production work.

+The prototype can be viewed at
+<a href="http://svn.boost.org/svn/boost/sandbox/filesystem-v3/">
+http://svn.boost.org/svn/boost/sandbox/filesystem-v3/>
+
+There is a (partial) TO DO list at the beginning of
+<a href="http://svn.boost.org/svn/boost/sandbox/filesystem-v3/boost/filesystem/path.hpp">
+http://svn.boost.org/svn/boost/sandbox/filesystem-v3/boost/filesystem/path.hpp>
+
+<h2><a name="Trying-the-prototype">Trying the prototype</a></h2>
+
+<blockquote>
+ <pre>svn export http://svn.boost.org/svn/boost/trunk filesystem-v3
+rmdir /s /q filesystem-v3/boost/filesystem
+rmdir /s /q filesystem-v3/libs/filesystem
+svn --force co http://svn.boost.org/svn/boost/sandbox/filesystem-v3 filesystem-v3</pre>
+</blockquote>
<h2><a name="Acknowledgements">Acknowledgements</a></h2>

-Walter Landry contributed both the design and implementation of the copy_any,
+Peter Dimov suggested the idea of a single path class that could cope with
+multiple character types and encodings. Walter Landry contributed both the design and implementation of the copy_any,
copy_directory, copy_symlink, and read_symlink functions.

<hr>
Revised
-24 January, 2009
+01 February, 2009

© Copyright Beman Dawes, 2008
 Use, modification, and distribution are subject to the Boost Software

Added: sandbox/filesystem-v3/libs/filesystem/index.html
==============================================================================
--- (empty file)
+++ sandbox/filesystem-v3/libs/filesystem/index.html 2009-02-01 09:38:12 EST (Sun, 01 Feb 2009)
@@ -0,0 +1,14 @@
+<html>
+<head>
+<meta http-equiv="refresh" content="0; URL=doc/index.htm">
+</head>
+<body>
+Automatic redirection failed, please go to
+doc/index.htm.
+<hr>
+© Copyright Beman Dawes, 2003
+ Distributed under the Boost Software
+License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at <a href="http://www.boost.org/LICENSE_1_0.txt">
+www.boost.org/LICENSE_1_0.txt</a>)
+</body>
+</html>

Deleted: sandbox/filesystem-v3/libs/filesystem/readme-sandbox-v3.html
==============================================================================
--- sandbox/filesystem-v3/libs/filesystem/readme-sandbox-v3.html 2009-02-01 09:38:12 EST (Sun, 01 Feb 2009)
+++ (empty file)
@@ -1,26 +0,0 @@
-<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 Version 3 in the Sandbox</title>
-</head>
-
-<body>
-
-<h1>Filesystem Version 3 in the Sandbox</h1>
-To experiment with filesystem.v3:
-<ul>
- <li>Subversion export trunk into a temporary directory:
- http://svn.boost.org/svn/boost/trunk>
- <li>From the trunk temporary, delete temporary-root/boost/filesystem and
- temporary-root/libs/filesystem</li>
- <li>Subversion checkout filesystem-v3 from the sandbox: http://svn.boost.org/svn/boost/sandbox/filesystem-v3>
- <li>Move temporary-root/* to the filesystem-v3-root just checked out.</li>
-</ul>
-
-</body>
-
-</html>

Next message: bdawes_at_[hidden]: "[Boost-commit] svn:boost r50952 - in sandbox/filesystem-v3: boost/filesystem libs/filesystem/doc libs/filesystem/src libs/filesystem/test"
Previous message: chris_at_[hidden]: "[Boost-commit] svn:boost r50950 - trunk/libs/asio/doc/overview"

Date view	Thread view	Subject view	Author view