On 8/6/07, Buck Huppmann <[EMAIL PROTECTED]> wrote:
> sorry to drag the other guys into this; they may no longer be interest-
> ed. for my part, getting rsync hacked up to fit into a tool-chain to
> suit my bidding was about as much ambition as i had. setting up this
> frep thing seems like Real Wo
On 7/30/07, Matt McCutchen <[EMAIL PROTECTED]> wrote:
> Currently, I think the best option is to do a separate rsync run for
> each notification (or group of notifications arriving close in time).
> Write a little script that reads the inotifywait output [...]
I was going to hack together a script
On 8/5/07, Buck Huppmann <[EMAIL PROTECTED]> wrote:
> i'm just worried that the code is gonna collapse under the weight of
> so many options at some point--sorta like Windows
That's a legitimate concern and one that I have thought about myself.
I suppose it depends on what you mean by "collapse".
On 8/5/07, Buck Huppmann <[EMAIL PROTECTED]> wrote:
> GNU cpio
> (Debian 4.0/2.6-17) doesn't object to being treated so perversely. of
> course, you have to work around stdio buffering . . .
OK, so cpio appears to be a good option for continuous copying using a
single process. I personally would
On Mon, Jul 30, 2007 at 02:27:14PM -0400, Matt McCutchen wrote:
> The current design of incremental recursion is that all of the source
> arguments or --files-from entries are loaded into the file list at the
> beginning but traversal of directories happens little by little. The
> key point is th
On 7/29/07, Buck Huppmann <[EMAIL PROTECTED]> wrote:
> i may be reading the code incorrectly, but it seems that, if the
> --files-from option processing can be altered (or perhaps yet another
> option could be created [shudder]) to opt out of the de-duplicate pass
> and somebody hooked inotifywait
Way back,
On Fri, Jan 12, 2007 at 08:12:30AM +, Wayne Davison wrote:
> On Thu, Jan 11, 2007 at 05:22:55PM -0500, Matt McCutchen wrote:
> > Specifically, I'm curious about what areas under the source
> > argument(s) are scanned at what time.
>
> All the args that the user supplies are scanned a
On Tue, 31 Jan 2006, Ryan Kather wrote:
> I'm looking for a way to continually monitor at least one but possibly
> multiple directories (and/or individual files). I would like RSYNC to
> immediately synchronize the changes to said directory(ies) after they
> occur. I believe the best approach
I'm looking for a way to continually monitor at least one but possibly multiple
directories (and/or individual files). I would like RSYNC to immediately
synchronize the changes to said directory(ies) after they occur. I believe the
best approach for this would be to utilize iNotify enabled ker