boost::filesystem::rename - behavior/code vs. docs

[repost] This is what documentation on boost::filesystem::rename states: http://www.boost.org/libs/filesystem/doc/tr2_proposal.html template <class Path1, class Path2> void rename(const Path1& from_p, const Path2& to_p); Requires: Path1::external_string_type and Path2::external_string_type are the same type. Effects: Renames from_p to to_p, as if by POSIX rename(). Postconditions: !exists(from_p) && exists(to_p), and the contents and attributes of the file originally named from_p are otherwise unchanged. [Note: If from_p and to_p resolve to the same file, no action is taken. Otherwise, if to_p resolves to an existing file, it is removed. A symbolic link is itself renamed, rather than the file it resolves to being renamed. -- end note] Actual effect is that an exception is thrown when renaming a file to an existing file on the same fs. rename(2) performs an 'atomic' rename in this case without problems, but in the boost code there is a specila check against "too permissive" posix rename(): http://boost.cvs.sourceforge.net/boost/boost/libs/filesystem/src/operations.cpp?revision=1.23.2.4&view=markup 1126 rename_api( const std::string & from, const std::string & to) 1127 { 1128 // POSIX is too permissive so must check 1129 fs::system_error_type dummy; 1130 if ( fs::exists( status_api( to, dummy ) ) ) 1131 return EEXIST; 1132 return std::rename( from.c_str(), to.c_str() ) != 0 1133 ? errno : 0; 1134 } And rename testing code also checks for the above behavior. I think that this is a huge difference between the docs and the code, and this is very counter-intuitive too. -- Andriy Gapon
participants (1)
-
Andriy Gapon