On Tue, May 12, 2009 at 10:39 AM, Jerry Leichter <leich...@lrw.com> wrote:
> On May 11, 2009, at 8:27 PM, silky wrote:
> >
> > The local version needs access to the last committed file (to compare
> > the changes) and the server version only keeps the 'base' file and the
> > 'changes' subsets.
> a)  What's a "committed" file.

I'm thinking an SVN-style backup system. When you're done with all
your editing, you just commit the changes to go into the backup. As
part of the commit operation, it decides on the amount of changes
you've done and whether it warrants an entire re-encrypt and upload,
or whether a segment can be done.

> b)  As in my response to Victor's message, note that you can't keep a base
> plus changes forever - eventually you need to resend the base.  And you'd
> like to do that efficiently.

As discussed in my original post, the base is reset when the changes
are greater then 50% of the size of the original file.

> > So yes, it does increase the amount of space required locally (not a
> > lot though, unless you are changing often and not committing),
> Some files change often.  There are files that go back and forth between two
> states.  (Consider a directory file that contains a lock file for a program
> that runs frequently.)  The deltas may be huge, but they all collapse!

In that specific case, say and MS Access lock file, it can obviously
be ignored by the entire backup process.

> > and
> > will also increase the amount of space required on the server by 50%,
> > but you need pay the cost somewhere, and I think disk space is surely
> > the cheapest cost to pay.
> A large percentage increase - and why 50%? - scales up with the amount of
> storage.  There are, and will for quite some time continue to be,
> applications that are limited by the amount of disk one can afford to throw
> at them.  Such an approach drops the maximum size of file the application
> can deal with by 50%.

No reason for 50%, it can (and should) be configurable. The point was
to set the time at which the base file would be reset.

> I'm not sure what cost you think needs to be paid here.  Ignoring
> encryption, an rsync-style algorithm uses little local memory (I think the
> standard program uses more than it has to because it always works on whole
> files; it could subdivide them) and transfers close to the minimum you could
> possibly transfer.

The cost of not transferring a entirely new encrypted file just
because of a minor change.

noon silky

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to