variable lookups possible?

[Chad McWilliams]

> -----Original Message-----
> From: filepro-list-bounces at lists.celestial.com 
> [mailto:filepro-list-bounces at lists.celestial.com] On Behalf 
> Of Fairlight
> Sent: Wednesday, July 21, 2004 1:48 PM
> To: filepro-list at celestial.com
> Subject: Re: variable lookups possible?
> 
> 
> On Wed, Jul 21, 2004 at 02:32:28PM -0400, Walter Vaughan may 
> or may not have proven themselves an utter git by pronouncing:
> > Fairlight wrote:
> > > I now believe that I can make the pseudo-RSS parsing module a 
> > > reality
> > 
> > How does this add any fuctionality that rsync doesn't 
> already offer? 
> > Interesting minds want to know.
> 
> Glad you asked.  I just went through the man page for rsync 
> again to make sure, (rsync 2.5.6 protocol 26)
> 
> Basically the docs even claim it's basically just a fancy 
> replacement for rcp that can use multiple transport layers.
> 
> The problem with this is that it has no way to let fP know 
> that it may be working on the file (ie., it may be only 
> partially copied/diff'd at any given point during its execution).
> 
> In short, you could end up working with a corrupt table if 
> you hit something at the wrong time.  The docs for rsync make 
> zero mention of any sort of file locking options or 
> functionality.  Every search for 'lock' only referred to 
> blocking/non-blocking I/O, or the block size.  In short, I 
> think it's unsafe for use during fP's continued operation, 
> and you couldn't really rely on this without making fP 
> inaccessible via some downtime with httpd, or via code that 
> checks for a lockfile that's created/removed by a wrapper 
> around rsync, etc.
> 
> My plan makes it more transactional, where you use fP itself 
> to make any changes using its own mechanisms, thus relying on 
> its own locking to make sure nothing is currently unusable.  
> You're also never actually mangling the disk layer by 
> altering the file itself.  So Bill Vermillion's trick of 
> pre-expanding files and letting them sit and just fill up so 
> they never fragment would still work, whereas I suspect rsync 
> may defeat that scheme.
> 
> Yes, you could rsync more than nightly, or even a few times a 
> day.  But as you do, your chances of colliding would 
> naturally go up.  :(
> 
> This avoids all of that.
> 
> mark->
> -- 
> Bring the web-enabling power of OneGate to -your- filePro 
> applications today!
> 
> Try the live filePro-based, OneGate-enabled demo at the following URL:
>                http://www2.onnik.com/~fairlite/flfssindex.html
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com 
> http://mailman.celestial.com/mailman/listinfo/> filepro-list
> 

2 things:

According to an article I just read (and seems to work in my
situations), rsync will just copy the differences in the file, not the
whole file.  So it is better than rcp or scp for updates.

But it would not be good in the following situation that we have, that I
believe Mark's program could be put to use in:

We have 4 locations, each with there own server.  We each run the same
filePro program, but each in different qualifiers so that they can be
combined at the head office without overwriting one of the others data.
What I would like to end up with someday is that we are all running in
the same qualifier, and that there would be an update system to allow
each server to notify the others of changes.  This way all of the data
from our locations would be directly available as a whole without any
kind of massaging.  

What Mark has proposed sounds like it could be used for a situation like
this.

-Chad McWilliams