Beman Dawes <bdawes@acm.org> writes: | 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. Sure let the default be that target is not overwritten, but removing the option... | >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. In that sense security is in the eye of the beholder... at least I do not find a system that ask nagging questions more secure that one that doesn't. Having the possiblity of ressurecting a file that was accidentally deleted otoh... | >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. So therefore why not make it impossible with boost.filesystem? and by forcing a remove(<file>) && copy_file(<target>, <file) it opens up for the race mentioned in another comment in this thread. | 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." The argument is not "shells do it that way". But "cp" does it that way. "cp" is not a shell it is a program specialized for copying files. Also that by not allowing overwrite of existing files it opens up for a race. -- Lgb