[Unison-hackers] Sneaker Net or Incremental Backup

[bcpierce@seas.upenn.edu]

That's a nice hack -- I had no idea the new copyprog functionality  
could be used that way.  Will be interested to hear whether it works...

     - Benjamin

Quoting Duane McKinney <duane.mckinney at gmail.com>:

> Or from Version 2.31.4
> copyprog xxx
>      A string giving the name of an external program that can be used to
> copy large files efficiently (plus command-line switches telling it to
> copy files in-place). The default setting invokes rsync with appropriate
> options—most users should not need to change it.
>
> copyprogrest xxx
>      A variant of copyprog that names an external program that should be
> used to continue the transfer of a large file that has already been
> partially transferred. Typically, copyprogrest will just be copyprog
> with one extra option (e.g., –partial, for rsync). The default setting
> invokes rsync with appropriate options—most users should not need to
> change it.
>
> copythreshold n
>      A number indicating above what filesize (in kilobytes) Unison
> should use the external copying utility specified by copyprog.
> Specifying 0 will cause all copies to use the external program; a
> negative number will prevent any files from using it. The default is -1.
> See the Making Unison Faster on Large Files section for more information.
>
> I guess I should have checked out the Beta Documentation 1st.  I'll try
> messing around with using a shell script as the copyprog.  I would
> assume that it would work just fine.  My plan is to write a shell script
> which ignores the destination unison tells it, and instead copies it to
> a usb drive.
>
> I'll probably report back on this in a week or so.  Currently I am
> running 2.27, so I have some compiling and testing to do.
>
> Duane McKinney wrote:
>> What about a flag that tells it to instead of executing the copies, just
>> prints out a list of the files that would be copied?  A proper name is
>> escaping me at the moment, but it is a common option on programs.
>>
>> Benjamin Pierce wrote:
>>> Both of these features would be easy to implement using information
>>> that Unison already has available.  If you want to give it a try, I
>>> can tell you where to start.  (I'd be reluctant, though, to add this
>>> code to the main sources -- Unison arguably has too many flags and
>>> switches already!)
>>>
>>> Best,
>>>
>>>      - Benjamin
>>>
>>> On Dec 27, 2008, at 10:27 AM, Duane McKinney wrote:
>>>
>>>> I searched, but came up empty.  Can this be done.
>>>> I sync two offices using unison.
>>>> 1) (Optional)I would like to be able to set a preference that says,
>>>> don't try to
>>>> sync a file if it would require X bytes transferred
>>>> 2) Get a list of changed files from a root.  That way I can copy the
>>>> files to a
>>>> removable drive and sync them when I get to the other office.
>>>>
>>>> Here is my reasoning.  Most of the time, root changes are very
>>>> small, a few MB.
>>>> But Let's say that I download a new CENTOS release and place it on
>>>> the file
>>>> server.  This may be a poor example, because I could retrieve it
>>>> over the
>>>> internet again, but just bear with me.  I would like for unison, to
>>>> instead of
>>>> trying to sync this file over the network to skip it.  The I would
>>>> like to be
>>>> able to say once a week, run a job, that would take the differences
>>>> in the root
>>>> and sent them to a USB drive.  I can then carry this drive to
>>>> location 2, and
>>>> update the root there.   Then from my understanding, the network
>>>> sync would
>>>> detect that both roots are identical.
>>>>
>>>> That way, our bandwidth isn't being eaten up for hours/days, trying
>>>> to perform a
>>>> sync that will most likely fail because it will take so long.
>>>>
>>>> Also, this would be more useful, than synchronizing the whole root
>>>> to a usb
>>>> drive, because, the total of the data that I am synchronizing is >
>>>> 1TB.  I would
>>>> not mind moving a few GB (<100) via USB.  I am trying to avoid
>>>> needing either, a
>>>> lot of time, or a bunch of USB drives (one for each root).
>>>>
>>>> I have not yet looked at the source, but I would assume that most of
>>>> the items
>>>> required for this feature are already in place.  Is it feasible?  Is
>>>> there
>>>> already a way?
>>>>
>>>> _______________________________________________
>>>> Unison-hackers mailing list
>>>> Unison-hackers at lists.seas.upenn.edu
>>>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>
>