[Box Backup-dev] observation with client side cached state file

[Nick Knight]

I think you should trust the server to do this so I agree, however you
do need to make allowances for corruption on the server (or other
extreme scenarios), this even in the best laid out plans will happen.

-----Original Message-----
From: boxbackup-dev-admin@fluffy.co.uk
[mailto:boxbackup-dev-admin@fluffy.co.uk] On Behalf Of Ben Summers
Sent: 26 July 2006 11:24
To: boxbackup-dev@fluffy.co.uk
Subject: Re: [Box Backup-dev] observation with client side cached state
file


On 26 Jul 2006, at 01:27, G. wrote:

>> However, if nothing changed on the client, then bbackupd wouldn't
>> have contacted the store and so wouldn't have learnt of the change.
>
> If that is the case, it would be beneficial to modify bbackupd to =20
> check the marker before it tries
> to run a cycle (to be on the safe side).

So you're suggesting that the daemon connects at the beginning of =20
every sync, at the very least?

This is only going to be a problem if the files on the client never =20
change or change very infrequently. Should we be worried about this =20
scenario?

One of the design criteria for the system is that you trust the =20
server to keep hold of your encrypted data (but that's the only trust =20
you put in it).

Ben





_______________________________________________
Boxbackup-dev mailing list
Boxbackup-dev@fluffy.co.uk
http://lists.warhead.org.uk/mailman/listinfo/boxbackup-dev