variable lookups possible?

[Fairlight]

You'll never BELIEVE what Bill Vermillion said here...:
> 
> Did you miss the part that rsync is much faster when the far
> file exists, and then only transmits the diffs of the files and
> then edits the far file using those diffs. It also used file
> compression to make transfer time shorter.

I've known that for a long time.  That doesn't mean you couldn't hit a
condition where it's not in partial progress on a file, or it's done an
index but not the key and you seek to the wrong place, etc.

> That surely sound like it is far more than a 'fancy replacement for
> rcp'.

It has bells and whistles, yes.  I wasn't belitting rsync at all.  I was
-quoting- (or at least paraphrasing) from the man page itself, as released
by the developers.  :)  It uses the same basic mechanism--altering the file
directly with a rewrite.  Not good if you're in the middle of something
with another program on that file.

> Current version of rsync is 2.6.2_1

Yeah, well, I reported the latest I had access to as installed, which was
from SuSE 9.0.  And you know how linux vendors are with their rpm
backports.  The actual rpm versioning is rsync-2.5.6-176, so it's had 176
revisions of that package, ostensibly.  It's probably roughly equivalent.

> > 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).
> 
> Valid point.

Thanks.  :)  I was responding inline (something I should probably stop
doing--it keeps biting me).  If there was a way to protect against that, I
would have expected you'd know it.  I know you're a big rsync
user/advocate.  That you just said it was a valid point means I didn't
overlook the obvious, at least.

> Snapshots dont take too long. Then you can backup the snapshot
> while the system continues.    Once you make a snapshot, you can
> copy it, make a tape backup, dump it, etc.    Snapshots also mean
> that you can be up and running after an inadvertent reboot without
> waiting a long time - probably over an hour or so on a
> multi-terabyte file-system.  Charts on his site shows it
> takes 3.5 seconds to snapshot a 7.7GB file system on an idle
> system and 12.1 seconds to snapshot on active file system.

Is this much different than the snapshots I'm used to with a .snapshot
directory on Network Appliance RAID servers?  Every directory has one, and
I have 10 hourly, 9 daily, and one master tape backup directory under that,
and can restore a file from any of them (which are all made at different
times during the day, obviously) that I choose.  That's saved me more
than once--not even just from accidental file removals, but even when I
-thought- something would be easier to code than it was, I did it wrong,
and need to revert and hadn't made a manual copy in advance, thinking it
would be a cake walk.  Sometimes reversion and starting over from a
known-good point is easier than trying to hammer on something for hours
when it's broken past a certain point.

> Night-time rsync usually isn't a problem, but as you point out it
> can be during the day.  The snapshot can be run often.  That means
> if someone accidentally deletes a file they can retrieve it from
> the earlier snapshot.   Since a snapshot only copies only block
> that are actively used they dont take up that much space.

But you're still altering a file that something else is actually accessing
already (potentially), are you not?

> Really interesting concept.  And a good read.

I'll have a look in my copious free time.  :)

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