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

From: Lars Gullik Bjønnes (larsbj_at_[hidden])
Date: 2005-01-29 21:17:55

Beman Dawes <bdawes_at_[hidden]> 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