[SOLVED] cp erroneously 'will not overwrite' because of duplicate filenames

compused · 07-15-2012, 05:22 AM

I am trying to restore time & date stamps to files that lost those attributes a year or so ago in a server migration. So I am trying to select and copy the new files created since the migration to (a copy of) the original files, which will then become the working directory:

Code:

find /share/_docs/* -newer ./DateFile -print0 | xargs -0 cp -Rp -t /share/_docs2

where ./DateFile carries the timestamp of the server migration.

A problem arises because of the presence of duplicate filenames, and even though they are quarantined in different directories, cp stops with the error msg:

Code:

cp: will not overwrite just-created (filename) with (same filename but in different directory)

I have found this reference, which I can't really follow:
http://stackoverflow.com/questions/2...lder-structure

Could anyone help?
Compused

rknichols · 07-16-2012, 12:39 AM

Your find command is matching on both files and directories. When it encounters a directory, it passes that name to cp, which replicates that subtree, including both new and old files, in the target directory, /share/_docs2. But then, find itself recurses into that directory, finds any new files (and subdirectories again!), and passes those names to cp, which will copy them directly into /share/_docs2. If in _docs you have this:

Code:

dir1/
     file1
     subdir1a/
              file1a

and all of the files and directories satisfy the "-newer" test, the command line produced by xargs will be:

Code:

cp -Rp -t /share/_docs2 \
    /share/_docs/dir1 /share/_docs/dir1/file1 /share/_docs/dir1/subdir1a /share/_docs/subdir1a/file1a

and your result in /share/_docs2 will be this:

Code:

dir1/
     file1
     subdir1a/
             file1a
file1
subdir1a/
        file1a
file1a

The whole tree gets replicated in the target, but every element of that tree gets copied again directly to the target directory, regardless of its original place in the tree. Any duplicate names will cause a conflict, but that is really secondary to the whole operation being fundamentally flawed.

A quick solution to this eludes me at the moment. Anyone???

compused · 07-16-2012, 07:58 AM

thanks rk, you have explained why the output from the string is quite a mess. My efforts with this approach have been exhausted. If I know more about Perl perhaps that would be an option
Compfused

rknichols · 07-16-2012, 02:11 PM

I believe this will do the trick:

Code:

find /share/_docs -newer ./DateFile -printf '%P\0' | rsync -a --from0 --files-from=- /share/_docs /share/_docs2

Note that in rsync the "--files-from" option implies:

--relative (preserves the path information for each item in the file)
--dirs (creates directories specified in the list rather than noiselessly skipping them)
Changes the "-a" (--archive) option so that it does not imply recursion.

The result is that find sends null-terminated names without the leading "/share/_docs" component in a list that rsync reads on stdin ("--files-from=-"). rsync then looks for these names in /share/_docs and copies what it finds, preserving the path read from find, to the destination, all without doing any recursion itself.

compused · 07-17-2012, 08:57 AM

Hi rk....thanks very much for working on this....

First 3 lines of output are:

Code:

find: unrecognized: -printf
BusyBox v1.10.3 (2010-05-17 05:57:25 UTC) multi-call binary

Usage: find [PATH...] [EXPRESSION]

It is not recognising 'printf'

Any ideas?

rknichols · 07-17-2012, 09:46 AM

How lovely -- a stripped-down version of find that lacks the "-printf" action. OK, let's use another way to keep find from including the "/share/_docs" part of the paths in its output:

Code:

cd /share/_docs && find . -newer /full/path/to/DateFile -print0 | rsync -a --from0 --files-from=- . /share/_docs2

You'll have to adjust that "/full/path/to/DateFile", of course.

compused · 07-18-2012, 10:25 AM

Hi rk
Thanks again, I should have alerted that busybox was involved.
I think we have a solution!

Initially the script did not work as I had failed to correctly transcribe the first part of the script, ie I had

Code:

find /share/_docs

instead of

Code:

cd /share/_docs && find .

It shows how much of this I don't fully understand!
Thanks again rk,
Compfused (somewhat less compfused now at least!)