[Box Backup] Suggested change in behaviour

[Ben Summers]

On 21 Sep 2004, at 00:24, Chris Wilson wrote:

> Hi all,
>
> First post, please don't flame me too bad, yadda yadda :-)
>
> On Mon, 20 Sep 2004, Pascal Lalonde wrote:
>> The more I think about it, the more I believe that letting the server
>> decide when to erase what is a bad idea.
>>
>> Or at least there should be a way to tell the server, through the
>> client, never to erase anything without being told to.
>
> I agree with this. The client decides voluntarily not to exceed the 
> soft
> limit of storage space. It could also decide, according to a policy 
> set by
> its owner, when to delete expired copies of data.

While the client controls when data is uploaded, the server controls 
when it is removed.

>  One such policy might be
> to retain copies of deleted files for 7 days, in which case you would 
> be
> safe as long as:
>
> - you realised your mistake soon enough
> - the feature to restore to a previous date (sim-tag) was implemented
> - deletion-date was versioned as well, so that the client knows that 
> the
>   files were not deleted on the requested date, but later.

I was planning a system of tagging which would efficiently allow sets 
to be marked. The server would then keep a record of sets. Sets could 
be marked for preservation in which case the server would not delete 
files from them. When files were deleted, sets affected would be marked 
as incomplete.

 From the client side, you would be able to list the sets available, and 
select any one as your current view.

This is all possible, but there's quite a bit of code which needs to be 
written to do it well. Quite apart from writing the automated tests for 
all this, which is going to be a nightmare.

However, this doesn't make a quick and simple safety check useless. I 
might put it in anyway, even though it is not the correct and final 
solution.

Ben

PS: Thanks for all the reports of success with 0.07PLUS3 and 0.07PLUS4 
-- keep them coming!