Re: cp/mv with verify step?
- From: Jules <jules.richardsonnews@xxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 17 Mar 2009 09:03:43 -0500
On Tue, 17 Mar 2009 09:14:30 +0000, Chris Davies wrote:
Remember that the wildcards get expanded by the shell, not by cp (or your
script), so a quick'n'dirty check would be to see if the last argument
is a directory (in which case you append each source filename in turn)
or a file (in which case you should have only one source filename,
and it becomes a copy/rename function).
Duh, yes... brain fart on my part. :-) That makes a scripted route a lot
more viable, I think. There's likely some fun and games to be had if one
of the 'source' arguments is a directory rather than a file, though - I'll
have a ponder as to what I want correct behaviour to be there.
One thing I might think about some more is simply calculating an MD5
sum of every single "source" file on the system, then copy data to a
target area (restructuring as needed), then creating a similar MD5 list
for every "target" file. I can then check things off, making sure that
every entry in the source list exists somewhere in the target - and if
that works out OK, I can ditch all the data in the "source" area.
If you're wanting to be that cautious, you'll almost certainly want to
look at comparing permissions and owner/group attributes, too. Do you
need to consider per-file ACLs, or file modification times?
I don't think file mod times are an issue as the data's all come from
several sources (which is why it needs organising in the first place) and
so timestamps against the true "originals" are probably different in a lot
of cases. But yes, I want to preserve owner/group IDs and access
permissions, though (probably a case of fist copying the file, then
issuing a chmod / chgrp call, and rolling back if the latter two fail).
Generating the lists *could* be scripted, but cross-checking the lists
might require some code, I think - and if so it might be easier to just
code the list generation bit too and make use of the same data
structures (plus I wrote some C code recently to walk a filesystem,
and I could re-use that)
'course then I think "hey, it'd be nice to maintain a database of file MD5
sums for the server anyway", and then I start looking at inotify and
storing the data in something other than an ASCII file and it all gets
silly ;-) (that's been a back-burner project for a couple of years, and
I've never quite got the tuits together to implement it)
Needs 2x disk space to hold two copies of all the data in parallel, but
that's not an issue...
Since you've got the space, treat your source as one instance of the
"backup" we've mentioned. Like you imply, there's no point breaking the
original until the destination's in place.
Yep. Paranoia will just set in when I get to the rm -rf point on the
source tree ;)
Even if I do go that route, some sort of "cp with verify" seems a
worthwhile thing to have for future cases, so I'll give that some more
thought - shame there's not a way of making it a default for every app on
the system, though (i.e. it'd be nice if the choice of binary for
doing the move/copy was independent of whether it did the verify or not).
cheers
Jules
.
- Follow-Ups:
- Re: cp/mv with verify step?
- From: Chris Davies
- Re: cp/mv with verify step?
- References:
- cp/mv with verify step?
- From: Jules
- Re: cp/mv with verify step?
- From: Chris Davies
- Re: cp/mv with verify step?
- From: Jules
- Re: cp/mv with verify step?
- From: Chris Davies
- cp/mv with verify step?
- Prev by Date: Re: cp/mv with verify step?
- Next by Date: Re: cp/mv with verify step?
- Previous by thread: Re: cp/mv with verify step?
- Next by thread: Re: cp/mv with verify step?
- Index(es):
Relevant Pages
|
Loading