[Box Backup] Suggested change in behaviour

[Pascal Lalonde]

On Mon, 2004-09-20 at 09:39, Ben Summers wrote:
> * If bbackupd finds that the root of a Location (as specified in 
> bbackupd.conf) contains no files or directories, it
> 
>     - will log a message "Backup location /x is empty, not changing 
> store" at level LOG_ERR
> 
>     - will not modify the relevant location on the server
> 
> Can anyone see any situation where this might cause problems? This will 
> only be triggered if there's absolutely nothing to back up in a 
> location.
I'm not sure the approach is good, because as soon as a file appears,
everything will be flagged as deleted. For example, I usually use
userquotas with /home. When rebooting, the quota.user file will be
created in /home, so this feature wouldn't help in that case.

To me this feels only as a dirty workaround for only one case of this
particular problem.

I think that the first thing to do when a drive fails is to *remember*
that you're running BoxBackup :-) But I guess I could've made that
mistake as well.

I agree about the e-mail though. And I think that the tag feature could
help this problem. Suppose that you setup the client so that it tags the
store with the date (200X-XX-XX) at the end of each day. Right after you
notice the death of your drive, you flag today's tag as read-only. Here
the e-mail could remind you that something weird is happening.

Or maybe everything should always be read-only (even if flagged as
deleted). And the user can set a limit so that he gets a warning when
that limit is reached, and then HE can order the server to do a cleanup
of files which are flagged as deleted.

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.

Pascal Lalonde