At 04:28 PM 1/25/2005, Lars Gullik Bjønnes wrote:
What is the rationale for having copy_file fail if the target file exists?
Better safe than sorry. I guess that design approach comes from my experience that in filesystem manipulations early detection of errors pays big dividends, even though you have to write more pedantic code.
This is not how any cp/copy in any shell I know of works, actually quite surprising.
The filesystem library isn't a shell. Even if it was, I think the modern trend is in favor of more rather than less security.
And with boost.filesystem there is no way to avoid this, short of rewriting the function to allow it. The other way around would have been easy: fs::exists(target) || fs::copy_file(source, target)
(One option is to delete the target before doing the copy, but then it is impossible to keep the same inode as before, and f.x. for backup files this is something that you want.)
Boost filesystem can't make guarantees about inodes; that isn't something that would be portable across various operating systems. Early in the development of the filesystem library, we tried providing a lot of shell-like options for various operations functions. That really didn't work; it is hard to choose option feature-sets that satisfy a majority of users. I'm not totally opposed to modifying the copy_file function in one way or another, but I'd want to hear stronger arguments that "shells do it a certain way." --Beman