How to log for "path/file" too long errors?

Support
1

I have a backup on my Windows server, running v2.0.4.5, that is now failing because it says that a file or path is too long, but unhelpfully not telling me what file/path:

2018-11-29 08:16:12 +01 - [Error-Duplicati.Library.Main.Operation.BackupHandler-FatalError]: Fatal error
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()

I have tried to enable logging hoping it will tell me in the logs but it’s not showing me any extra information:

"C:\Program Files\Duplicati 2\Duplicati.CommandLine.exe" backup "s3s://mybucket/?s3-server-name=s3.wasabisys.com&s3-location-constraint=&s3-storage-class=&auth-username=XXXXXX&auth-password=XXXXXX "C:\Users\administrator\\" "D:\Multimedia\Books\\" "D:\Multimedia\Music\\" "D:\Multimedia\Photos\\" --send-mail-url=smtp://mail.mydomain.com:25 --send-mail-from="machinename@mydomain.com" --send-mail-level=all --send-mail-to="myname@mydomain.com" --snapshot-policy=On --send-mail-subject="Duplicati %OPERATIONNAME% report for %backup-name% [%PARSEDRESULT%]" --usn-policy=On --backup-name="Wasabi Backup" --dbpath="C:\WINDOWS\system32\config\systemprofile\AppData\Local\Duplicati\SRUWJAURIA.sqlite" --encryption-module=aes --compression-module=zip --dblock-size=50mb --passphrase=XXXXXX --retention-policy="1W:1D,1M:1W,3Y:1M" --log-file-log-level=Profiling --console-log-level=Profiling --debug-output=true --disable-module=console-password-input

Except for hiding private info the above is the exported backup job as it is now. What should I be using to get the information?

2

FYI I was able to finally find the culprit using the following Powershell command:

cmd /c dir /A /s /b |? {$_.length -gt 260}

This might be usefui for someone else, but it would be nice for Duplicati to still log it in the first place.

3

This error happens inside the USN handling code, which is new in the beta release.

Unfotunately, the part of the code where the error happens does not have logging, and does not gracefully handle the error, making it difficult to get the path reported.

After the beta release was locked in, this problem with long paths has been fixed, but it was deemed to large to be included in the beta without more testing.

You can disable the USN code to work around this problem, which will not reveal the paths but should make the problem go away. Add --usn-policy=off to disable USN.

4

Thanks, but I’m confused by this - is or isn’t it fixed? If it was locked into the beta how can it be too large to be included?

This particular machine was running the last canary release, so I decided to go for the newer beta to see how it performed.

5

We picked the source code from the repo and locked it for beta. Then added the long path changes. So it is fixed in the canary builds, but not in the beta.

The canary generally has more features and fixes, but is less tested.

6

Ok understood, thank-you.

I reverted back to the canary and all is well again without needing to filter the long paths - although it confuses the MSI installer as it removes the service executable (or fails to add it), so it needs a “repair” install afterwards to get it going.