[Box Backup] 'MaxUploadWait' and reboot

[Benjamin Cotte]

Hi,

Thanks for the answer.

I made some tests to figure this out and it appears it is not always 
true, I think some of you might be interested I'll give some details.

If my file is modified on startup just before bbackupd starts (unlikely 
but still possible) it will not be uploaded even if it was not uploaded 
for several days in a row.

It looks like bbackupd doesn't asks the server for the last time a file 
was uploaded but keeps this information in its internal state. So when 
the daemon restarts this information is lost. The only solution I found 
is to reduce 'MaxUploadWait' lower than the uptime of my computers.


Le 18/03/2013 18:03, Pavol Cupka a écrit :
> yes,
>
> bbackupd will upload the file next time the computer is turned on.
>
> palica
>
>
> On Mon, Mar 11, 2013 at 11:18 AM, Benjamin Cotte 
> <benjamin.cotte at eliis.fr <mailto:benjamin.cotte at eliis.fr>> wrote:
>
>     Hi,
>
>     I've got a question about the 'MaxUploadWait' parameter.
>
>     Let's say i use the default configuration:
>
>     UpdateStoreInterval = 3600	# 1h
>     MinimumFileAge = 21600		# 6h
>     MaxUploadWait = 86400		# 24h
>
>     From now if I have a file that changes every 2 hours, it will be
>     backed up every 24 hours. But is it still true if the computer is
>     turned off every days? (never online for 24h in a row)
>
>     Thanks,
>
>     -- 
>     Benjamin Cotte
>     /Software Engineer/
>
>
>     _______________________________________________
>     Boxbackup mailing list
>     Boxbackup at boxbackup.org <mailto:Boxbackup at boxbackup.org>
>     http://lists.boxbackup.org/cgi-bin/mailman/listinfo/boxbackup
>
>
>
>
> _______________________________________________
> Boxbackup mailing list
> Boxbackup at boxbackup.org
> http://lists.boxbackup.org/cgi-bin/mailman/listinfo/boxbackup

-- 
Benjamin Cotte
/Software Engineer/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.boxbackup.org/pipermail/boxbackup/attachments/20130319/817b8ac3/attachment.html>