Trent W. Buck wrote:
> I don't think this is a bug, but I don't understand why only one
> (rather than both or none) of the following cp invocations fail:
> ...
> $ cp -bf x x
> $ ls
> x x.~1~
> $ cp -bf x ./
> cp: `x' and `./x' are the same file
A comment in the code probably explains it best.
/* When the force and backup options have been specified and
the source and destination are the same name for an existing
regular file, convert the user's command, e.g.,
`cp --force --backup foo foo' to `cp --force foo fooSUFFIX'
where SUFFIX is determined by any version control options used. */
if (x->unlink_dest_after_failed_open
&& x->backup_type != no_backups
&& STREQ (source, dest) <-- name compare
&& !new_dst && S_ISREG (sb.st_mode))
The comparison check triggering this behavior is for the names of the
files. This is a specific special case for that specific behavior.
The SOURCE and DEST names must be identical to trigger this behavior.
In your first case you are copying "x" to "x" these are the same and
this special behavior is triggered. In your second case you are
copying "x" to "./" which are different names and does not trigger
this behavior.
Bob
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
