Was a crashplan and previous duplicati 1.3.4 user. After the demise of crashplan did the dive into the ‘beta’ version. So far still testing out but really appreciate the new cloud services supported.
Something weird though - seems other cloud providers work ok but for Box.com - I end up getting strange error messages (“Got 0 warnings”).
Screenshot and some logs I could see provided. Anybody have insights why this is happening?
Not from my end. My experience with it was just with a test backup which has since gone away (forgot to save it before wiping a machine).
Knowing more about Duplicati now than I did back then my guess is that there’s either a bug in how box.com reports (via their API) files or a race condition such that a file recently uploaded to them isn’t reported (via their API) as existing if queried too soon after creation.
Since mine was very small test backup I believe I had a single archive (dblock) and “what’s-been-backed-up” (dlist) file set created. This meant that the automatic “test a single random archive file” step Duplicati does after a backup had to choose the only file that existed (and in this case was recently uploaded).
Do you know how many dblock files you have at your destination?
If I (or you) were to test this theory, some things to try out would include:
is the destination create date on the “requested file does not exist” error very recent?
do you have less than 5 or so dblock files?
does the error only happen sometimes (and does the error frequency drop as the number of dblock files increases)?
does enabling --no-backend-verificationPURELY AS A TEST stop the errors from happening?
If any (or most) of the above are “yes” then it’s most likely a race condition (Duplicati is asking for the file list faster than the destination is able to provide an up-to-date one).
@kenkendk, what do you think of retiring --no-backend-verification and replacing it with something like --backend-validation=before|after|none?
Considerations include:
Con: with the before setting on initial backups (esp. of small data sets) this potentially exposes a user to a bad backup not being detected until the next job run
Pro: should fully remove the related “file does not exist” scenario when caused by race conditions
Quick data point - I have --no-backend-verification set for other reasons (make backups faster coz the check increases the turn around time by a lot)
I used to have the box.com error but have noticed it hasnt come up for a while. So perhaps the theory is right (but take with a grain of salt since all anecdotal and not really scientifically tested)
I could have sworn I saw another post where somebody else reported using WebDAV worked better for them than the box.com API as well, but I can’t seem to find it now.
I found and fixed the error in the box.com backend, and I also found and fixed the “0 warning(s)” dialog. The fixes will be part of the next canary build.
Is it possible that box.com is no longer usabel in Duplicati? Can anyone post if he/she has the same problems or if it works?
Have a complete empty box.com free account.
Setup a new Backup in Duplicati - tried both webdav (SSL, dav.box.com:443 and path /dav/duplicati) and box.com with API key
I use Duplicati beta from Nov. Error is the same in both setups
Backup started at 20.07.2019 10:32:15
Checking remote backup ...
Listing remote folder ...
Listing remote folder ...
Listing remote folder ...
Listing remote folder ...
Listing remote folder ...
Fatal error => The underlying connection was closed: An unexpected error occurred on a send.
System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the
transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibl
y closed by the remote host
at System.Net.Sockets.Socket.EndReceive(IAsyncResult asyncResult)
at System.Net.Sockets.NetworkStream.EndRead(IAsyncResult asyncResult)
--- End of inner exception stack trace ---
at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)
at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)
--- End of inner exception stack trace ---
at Duplicati.Library.Main.BackendManager.List()
at Duplicati.Library.Main.Operation.FilelistProcessor.RemoteListAnalysis(BackendManager backend, Options options, LocalDatabase database, IBackendWriter log,
String protectedfile)
at Duplicati.Library.Main.Operation.FilelistProcessor.VerifyRemoteList(BackendManager backend, Options options, LocalDatabase database, IBackendWriter log, S
tring protectedfile)
at Duplicati.Library.Main.Operation.BackupHandler.PreBackupVerify(BackendManager backend, String protectedfile)
at Duplicati.Library.Main.Operation.BackupHandler.<RunAsync>d__19.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at CoCoL.ChannelExtensions.WaitForTaskOrThrow(Task task)
at Duplicati.Library.Main.Controller.<>c__DisplayClass13_0.<Backup>b__0(BackupResults result)
at Duplicati.Library.Main.Controller.RunAction[T](T result, String[]& paths, IFilter& filter, Action`1 method)
at Duplicati.Library.Main.Controller.Backup(String[] inputsources, IFilter filter)
at Duplicati.CommandLine.Commands.Backup(TextWriter outwriter, Action`1 setup, List`1 args, Dictionary`2 options, IFilter filter)
at Duplicati.CommandLine.Program.ParseCommandLine(TextWriter outwriter, Action`1 setup, Boolean& verboseErrors, String[] args)
at Duplicati.CommandLine.Program.RunCommandLine(TextWriter outwriter, TextWriter errwriter, Action`1 setup, String[] args)
Update "2.0.4.23_beta_2019-07-14" detected
We originally announced the end of our support for WebDAV effective on Jan 31, 2019. We are extending support for WebDAV beyond our originally-announced date.
