Re: [boost] boost.filesystem - rationale for copy_file

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
 >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