Release: 2.0.3.12 (canary) 2018-10-23


#1

2.0.3.12-2.0.3.12_canary_2018-10-23

  • Fixed translations not working for sub-cultures, thanks @LacunaSoftware
  • Improved error detection and reporting
  • Fixed progress bar not updating, thanks @LacunaSoftware
  • Improved LVM handling, thanks @jkellerer
  • Fixed issues with long paths and USN, thanks @dgehri
  • Numerous code quality improvements, thanks @warwickmm
  • Removal of unused code, thanks @Pectojin
  • Added backup description field to UI, thanks @sffetlio
  • Updated MegaApiClient to 1.6.3, thanks @Pectojin
  • Normalize paths by forcing Windows drive letters to upper case, thanks @mnaiman
  • Fixed progress stats gammar and consistency, thanks @lucascosti
  • Fixed server errors with empty form changes, thanks @LacunaSoftware
  • Improved error messages, thanks @warwickmm
  • Added US-West to Wasabi, thanks @gzzengwei
  • Added app manifest files for Windows, thanks @LacunaSoftware

#2

I upgraded a Windows machine to this and renabled USN, set it to “on”, the scheduled backup ran and I receive this still:

System.IO.PathTooLongException: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
 at System.IO.Path.LegacyNormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)
 at System.IO.Path.GetPathRoot(String path) at Duplicati.Library.Snapshots.UsnJournalService.IsPathEnumerated(String path)
 at Duplicati.Library.Main.Operation.BackupHandler.<>c__DisplayClass12_0.<RunMainOperation>b__2(String path, Int64 fileSize)
 at Duplicati.Library.Main.Database.LocalBackupDatabase.AppendFilesFromPreviousSetWithPredicate(IDbTransaction transaction, Func`3 exclusionPredicate, Int64 fileSetId, Int64 prevFileSetId, DateTime timestamp)
 at Duplicati.Library.Main.Database.LocalBackupDatabase.AppendFilesFromPreviousSetWithPredicate(IDbTransaction transaction, Func`3 exclusionPredicate) at Duplicati.Library.Main.Operation.Common.SingleRunner.<>c__DisplayClass3_0.<RunOnMain>b__0()
 at Duplicati.Library.Main.Operation.Common.SingleRunner.<DoRunOnMain>d__2`1.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Duplicati.Library.Main.Operation.BackupHandler.<RunMainOperation>d__12.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 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.Server.Runner.Run(IRunnerData data, Boolean fromQueue)

I’ve checked and there are definitely no long names/paths, though it would be nice if the error gave me a hint as to where to look.


#3

Article readers may refer to PathTooLongException when using USNJournal #3311 for newer status on this.


#4

Hi all!

I can’t download/install the update 2.0.3.12_canary_2018-10-23. It allways flips back to “update available”.


#5

I’m seeing the same thing on a Fedora box, other machines/browsers can’t seem to reliably download from “https://updates.duplicati.com/canary/duplicati-2.0.3.12_canary_2018-10-23.zip” it keeps stalling/failing and never completes.


#6

Also see Download links not working where a pointer to https://github.com/duplicati/duplicati/releases might work for a manual browser download, but I’m not sure whether the automatic updater is similarly affected by the issue.


#7

I deployed a fix for the update server and that broke downloads longer than 2 seconds.

I have fixed the problem with the server, and downloads work for me now.


#8

The updated version failed to automatically launch (as always), but other than that it appears to have gone smoothely. (For anyone else this happens to, just re-launch Duplicati manually).
[Windows 10]


#9

If it’s installed as a Windows Service, you might have to use Task Manager or Settings --> View local services, and if anyone on Windows wants to share their experience, see Activate downloaded upgrade sometimes fail.


#10

Nope, mine is a purely vanilla Windows install.


#11

Linux (Ubnuntu) upgrade from 2.0.3.11 worked (and restarted) fine with the following pre-existing exceptions:

  1. If connected to GUI “Show” screen with a password window never refreshes (I think it’s waiting, but not prompting, for a password) - manual reload of main page URL resolves this.

  2. After update, still get prompted that update is available.
    Found update


#12

@kenkendk, it looks like there was a database version update from 5 to 6 in this release. Has anybody tested if it’s possible to downgrade back to 2.0.3.11 yet?

Note that I’ve already updated this #howto on the assumption that a downgrade will NOT work:


#13

After upgrading to the latest canary, I started receiving the following error on the OneDrive v2 (personal) backend (some information redacted for privacy):

Failed to connect: BadRequest: Bad Request error from request https://graph.microsoft.com/v1.0/me/drive/root:Backup Portatil Method: GET, RequestUri: ‘https://graph.microsoft.com/v1.0/me/drive/root:Backup Portatil’, Version: 1.1, Content: , Headers: { User-Agent: Duplicati/2.0.3.12 Authorization: Bearer <bearer> } StatusCode: 400, ReasonPhrase: ‘Bad Request’, Version: 1.1, Content: System.Net.Http.StreamContent, Headers: { Transfer-Encoding: chunked request-id: <request-id> client-request-id: <client-request-id> x-ms-ags-diagnostic: {“ServerInfo”:{“DataCenter”:“North Europe”,“Slice”:“SliceC”,“Ring”:“2”,“ScaleUnit”:“000”,“Host”:“AGSFE_IN_27”,“ADSiteName”:“NEU”}} Duration: 10.5459 Strict-Transport-Security: max-age=31536000 Cache-Control: private Date: Sat, 27 Oct 2018 10:02:09 GMT Content-Type: application/json } { “error”: { “code”: “BadRequest”, “message”: “Resource not found for the segment ‘root:Backup Portatil’.”, “innerError”: { “request-id”: “<request-id>”, “date”: “2018-10-27T10:02:09” } } }

Maybe it is just a temporary issue with OneDrive, but the onset of the error does seem to coincide with my installation of the update. I haven’t been able to complete a backup job to this backend since.

May be relevant: I currently use the OneDrive v2 backend because I have second factor authentication enabled on OneDrive (this did work seamlessly in the previous canary).


#14

I have a fix for the OneDrive issue and will post it for review after some more testing. See the GitHub issue here:


Setting up OneDrive (personal)
#15

The database change was to add descriptions to backups. In principle that shouldn’t break anything.


#16

I just confirmed that downgrading from 2.0.3.12 -> 2.0.3.11 (on Windows 10) causes this error:

A serious error occurred in Duplicati: System.Exception: Failed to create, open or upgrade the database.
Error message:
The database has version 5 but the largest supported version is 4.

Putting 2.0.3.12 back in the updates folder got things running again.


#17

That’s why it’s in principle. The db version check still fails :slight_smile:


#18

I found that when i try to cancel a backup (stop after uploading) it never stops. Other than that, I’m pretty good.


#19

Hi @DisplayNerd, welcome to the forum!

Did you choose cancel “now” or “after upload completes”?


#20

It was stop after downloading. I just realized i had a very high async upload limit with not as much bandwidth, so it would normally take a long time to stop (don’t know why I did that). However, I left it stopping for over an hour and it changed back to regular uploading. When I forced stopped I got a warning next time I tried to upload. I promptly downgraded back to 2.0.3.3. Did the same procedure in 2.0.3.3 w/ same upload limit and everything was fine. It seems like this feature may be broken (could somebody test this)
P.S. I’m using the docker version and I also got the same bug with the upgrade dialog being shown after upgrade.