Hi! Please consider the code below: === BUG === boost::filesystem::path some_path("first"); char path_component[1]; /* = "second" */ some_path /= path_component; Some_path value is expected to be "first/second" but it is "first". I.e operator /= had no effect. === END BUG === Concerning a longer string in a char[1] buffer. Actually path_component is the *last* field in a heap-allocated structure. The structure is over-allocated to enable storing a longer string in a char[1] buffer. This technique is often used in C code. Here is operator /= callstack. #0 boost::filesystem3::path_traits::empty<char const, 1ul> () at path_traits.hpp:89 #1 0x0000000100001e7e in boost::filesystem3::path::append<char [1]> (this=0x7fff5fbff910, source=@0x100100270, cvt=@0x100100280) at path.hpp:655 #2 0x0000000100001f77 in boost::filesystem3::path::operator/=<char [1]> (this=0x7fff5fbff910, source=@0x100100270) at path.hpp:235 The relevant excerpt from boost::filesystem3::path_traits::empty follows: namespace path_traits { ... template <typename T, size_t N> inline bool empty(T (&)[N]) { return N <= 1; } ... } It appears that boost::filesystem::path treats char[1] as an empty path regardless of the actual content. This is definitely wrong due to so many C libraries storing long strings in char[1] buffers. In particular on Mac OS X fts(3) FTSENT::fts_name is char[1]. I believe the current operator =/ behavior is outright dangerous and should be fixed. By the way the only code currently benifiting from the boost::filesystem::path being overly smart is the code appending "" (empty string literal) to pathes.