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.
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.
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!
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%.
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.
If you want the delta computation to be done locally, you need two
local
copies of the file - doubling your disk requirements. In
principle, you
could do this only at file close time, so that you'd only need such
a copy
for files that are currently being written or backed up. What
happens if
the system crashes after it's updated but before you can back it
up? Do you
need full data logging?
I think this is resolved by saving only the last committed.
If a file isn't committed when closed, then you're talking about any
commonly-used system.
-- Jerry
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
