On Sat, Oct 06, 2007 at 10:34:07AM -0600, Bob Proulx 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 >> $ 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.
Ah, I didn't realize I was invoking a special case the first time. Do
you think it's reasonable for the comparison to be extended so you can
back up a whole bunch of files in one go? For example,
cp -fb foo?? .
split foo
instead of
for i in foo??
do cp -fb $i $i
done
split foo
If not, I see no problem in closing this bug.
signature.asc
Description: Digital signature
