From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-01-29 19:58:25
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
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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk