2.0.2.9: Backend verification failed, attempting automatic cleanup

After installation of version ’ 2.0.2.9_canary_2017-10-01’ I’m receiving the following error:

Backend verification failed, attempting automatic cleanup
System.ArgumentException: Object must be a root directory ("C:\") or a drive letter ("C").
   at System.IO.DriveInfo..ctor(String driveName)
   at Duplicati.Library.Backend.File.GetDrive()
   at Duplicati.Library.Backend.File.get_Quota()
   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, String protectedfile)
   at Duplicati.Library.Main.Operation.BackupHandler.PreBackupVerify(BackendManager backend, String protectedfile)

The destination is an UNC in the format \\\SERVER\Path.

Welcome to the forum! I edited your post to improve the formating. (Just added ~~~ before and after the output you pasted, see here for details).

It sound like you upgraded from something to 2.0.2.9 - if so, what version were you on before and how did you upgrade (in-app upgrade feature or manual download and install)?

Also, if possible can you provide the settings for the job that’s failing as a “Export as commandline…” (be sure to remove any personal data you might not want to share such as user name, password, finger hash, etc.).

I upgraded from 2.0.2.8 using the in-app feature.

I have another backup very similar pointing directly to a local drive and It works fine.

The configuration is:

"C:\Program Files\Duplicati 2\Duplicati.CommandLine.exe" backup "file://\\s0002\Data/?auth-username=xxxx&auth-password=yyy" "C:\Work\\" 
--log-file="C:\Temp\Duplicati\S0002.log" 
--log-level="Information" 
--symlink-policy="Follow" 
--log-retention="30D" 
--snapshot-policy="Auto" 
---send-mail-url="smtp://smtp.gmail.com:587/?starttls=when-available" 
--send-mail-any-operation="true" 
--send-mail-subject="Duplicati %PARSEDRESULT%, %OPERATIONNAME% report for %backup-name%" 
--send-mail-to="me@gmail.com" 
--send-mail-username="me@gmail.com" 
--send-mail-password="xxx" 
--send-mail-from="S0002 backup <s0002@gmail.com>" 
--backup-name="S0002" 
--dbpath="C:\WINDOWS\system32\config\systemprofile\AppData\Roaming\Duplicati\S0002 .sqlite" 
--encryption-module= --compression-module="zip" 
--dblock-size="5MB" 
--keep-time="6M" 
--passphrase="xxx" 
--no-encryption="true" 
--auto-cleanup="true" 
--verbose="false" 
--zip-compression-level="9" 
--disable-module="console-password-input" 
--exclude="*.log" --exclude="*.obj" --exclude="*.sbr" --exclude="*.xdc" 

Thanks.

Thanks for the commandline export - that all looks OK to me (ignoring likely re-formatting issues like the triple-dash before send-mail-url).

It looks like the argument exception may be a common problem with 2.0.2.9 - if you can’t wait until we hear from @kenkendk you might want to consider downgrading to 2.0.2.8, which seems to have worked for some people.

Out of curiosity, does it work any better if you change “C:\Work\” to “C:\Work\” (just add another slash after the colon)?

Thanks for the answer, I’ll roll back to version *.8

About the quote, I’m fairly sure the problem isn’t in the source part but in the destination, as I said I have another backup just like this one, but pointing to a local drive and folder and it works fine.

I have another one, with different sources sent to DropBox and it also works fine.

Nevertheless I made the change and started, the result is the same.

Thanks for testing. I suspect this is a regression issue POSSIBLY related to one of the changes around commit #2763 or so.

I can’t find the reference now but I thought I saw a change implementing a new IQuota interface and I know it’s easy to miss things when shifting to interfaces.

@kenkendk, what’s the best way to bring issues like this to your attention (here, Github, PM, …)?

It hasn’t been made available in a release yet but it looks like there might be a fix for this issue submitted at Github.

Oh, and I’m curious whether or not adding the --quota-size= parameter gets around the issue (if you feel like testing).

Nope, same error with the --quota-size= parameter.

Oh, well - it was worth a try, guess we’ll have to wait for the GetDriveFreeSpaceEx fix to come out in a Canary release. Thanks for testing!