Prev: Building TeX Live on -current
Next: seamonkey 2.0.3 upgrade on 12.2
From: Ewald Pfau on 9 Mar 2010 17:01
Mike Jones <Not(a)arizona.bay>:
> Responding to Ewald Pfau:
>
> [...]
>> With 'backup' enabled, the outdated stuff won't just disappear. rsync
>> will move it elsewhere. This is beyond of the capabilities of cp.
>
>
> cp --backup=numbered ???

Looks like suffix management, if I understand the manpage correctly.

But quite sure, it won't move a whole tree, selectively, to a
'deleted'-destination, which is a third path, additionally to source and
target.

From: Mike Jones on 9 Mar 2010 19:16
Responding to Ewald Pfau:

> Mike Jones <Not(a)arizona.bay>:
>> Responding to Ewald Pfau:
>>
>> [...]
>>> With 'backup' enabled, the outdated stuff won't just disappear. rsync
>>> will move it elsewhere. This is beyond of the capabilities of cp.
>>
>>
>> cp --backup=numbered ???
>
> Looks like suffix management, if I understand the manpage correctly.
>
> But quite sure, it won't move a whole tree, selectively, to a
> 'deleted'-destination, which is a third path, additionally to source and
> target.


Er, Eh?

--
*=( http://www.thedailymash.co.uk/
*=( For all your UK news needs.
From: Ewald Pfau on 10 Mar 2010 05:39
Mike Jones <Not(a)arizona.bay>:
> Responding to Ewald Pfau:

>> But quite sure, it won't move a whole tree, selectively, to a
>> 'deleted'-destination, which is a third path, additionally to source and
>> target.
>
> Er, Eh?

After rsync from source to target -> target-path is a clone of source-path.
And -> Anything different, that has been in target-path, is now in
'deleted'-path (so, has been moved selectively.)

From: Mike Jones on 10 Mar 2010 06:33
Responding to Ewald Pfau:

> Mike Jones <Not(a)arizona.bay>:
>> Responding to Ewald Pfau:
>
>>> But quite sure, it won't move a whole tree, selectively, to a
>>> 'deleted'-destination, which is a third path, additionally to source
>>> and target.
>>
>> Er, Eh?
>
> After rsync from source to target -> target-path is a clone of
> source-path. And -> Anything different, that has been in target-path, is
> now in 'deleted'-path (so, has been moved selectively.)


Ok, but with "cp --backup=numbered" you get copies of the replaced files
tagged with numbered suffixes. Whack away as many times as you like, and
you get just as many numbered backups. Isn't that a /useful/ thing?

I'm not seeing or experiencing a problem with "cp -backup=numbered" and
its an easy enough thing to bulk-delete all *~x~ files when done.

Horses for courses really.

--
*=( http://www.thedailymash.co.uk/
*=( For all your UK news needs.
From: JohnF on 10 Mar 2010 07:42
Grant <omg(a)grrr.id.au> wrote:
> JohnF <john(a)please.see.sig.for.email.com> wrote:
>> Grant <omg(a)grrr.id.au> wrote:
>>> GangGreene <GangGreene(a)example.com> wrote:
>>>> Greg Heilers wrote:
>>>>
>>>>> I would like to copy my existing set-up to a new and larger hard drive.
>>>>
>>>>rsync
>>>
>>> Seconded ;)
>>
>>I use rsync a lot, mostly to keep backups sync'ed. It's great.
>>But for "cloning" an entire directory structure from scratch,
>>I typically use cp -a as suggested earlier. Why do you guys
>>feel rsync's superior for this purpose, too?
>
> Possibly identical if you compare with 'cp -a', but sometimes it's easier
> to suggest rsync than explain why 'cp -aR' or 'cp -ar' could be very bad
> ideas (for hardlinks? I forget details).
> Rsync has a lots of worked examples in the man page too.
> Grant.

Thanks, Grant (ditto Ewald, Mike). Just wanted to check if
I was overlooking some useful rsync feature that would make
it preferable to cp -a for this purpose.
--
John Forkosh ( mailto: j(a)f.com where j=john and f=forkosh )
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Building TeX Live on -current
Next: seamonkey 2.0.3 upgrade on 12.2