Filepath longer than 256 bytes cause FileAccessError under Windows 7

currently running Duplicati - 2.0.4.34_canary_2019-11-05

Filepath longer than 256 bytes cause FileAccessError under Windows 7:
[Warning-Duplicati.Library.Main.Operation.Backup.FileEnumerationProcess-FileAccessError]: Error reported while accessing file

There are some Windows apps, which can read long filepaths, like Total Commander and Windows Explorer, some does not, like Faststone Viewer v6.5 or Duplicati.

I would welcome to have Duplicati in first group :wink:

I tested this and can’t reproduce the problem. I made 5 nested folders of 63 characters each and placed a file inside each one. Duplicati had no issue backing them all up from what I can see.

Here is a screen shot of the restore dialog:

This was on a test Win7 VM with a fresh install of Duplicati. Set up a blank backup job with all options at default settings.

Hmm.
Then how could I debug why those files are not accessible for Duplicati?

Can you post what options you are using at the main Duplicati settings level, and also what you’re using at the backup job level? (Sanitize any passwords or other sensitive info…)

I saw an older thread about how using --usn-policy may trigger this but it was older and I think it has been fixed.

A better log than the one-line default (which unfortunately drops most important details) might help.

Live log at About --> Show log --> Live --> Warning is one, or for long-term you could set a –log-file.

Reporting options also seem pretty good at emailing some of the detailed messages when jobs fail.

A completely different approach would be to see how Windows running as your Duplicati user does. Sometimes files have permission issues, or are locked. (–snapshot-policy can help get locked files).

v2.0.3.12-2.0.3.12_canary_2018-10-23

Fixed issues with long paths and USN, thanks @dgehri

v2.0.4.3-2.0.4.3_canary_2018-11-13

Rewrote path handling across the project to better support long paths, thanks @verhoek

Issue 3311 PathTooLongException when using USNJournal #3456 looks like it went in Nov 8, 2018.
Although not relevant to current topic, latest beta came from v2.0.3.14-2.0.3.14_canary_2018-11-08 meaning possibly it could show some long path problems. For current topic, I’d suggest a log check.

Can’t find it here on 2.0.4.34_canary_2019-11-05 over all four combinations of VSS and USN on/off however I’m seeing a worrisome non-detect of added files with USN on and VSS off. It needs a look.

FYI, our Windows build system (AppVeyor) has encountered the maximum path length issue. We are currently ignoring certain tests because of it.

I got errors like this in the error log:

   a következő helyen: System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   a következő helyen: System.IO.FileSystemEnumerableIterator`1.CommonInit()
   a következő helyen: System.IO.FileSystemEnumerableIterator`1..ctor(String path, String originalUserPath, String searchPattern, SearchOption searchOption, SearchResultHandler`1 resultHandler, Boolean checkHost)
   a következő helyen: System.IO.Directory.GetFiles(String path)
   a következő helyen: Duplicati.Library.Common.IO.SystemIOWindows.PathTooLongFuncWrapper[T](Func`2 nativeIOFunc, Func`2 alternativeIOFunc, String path, Boolean prefixWithUnc)
   a következő helyen: Duplicati.Library.Common.IO.SystemIOWindows.GetFiles(String path)
   a következő helyen: Duplicati.Library.Snapshots.NoSnapshotWindows.ListFiles(String localFolderPath)
   a következő helyen: Duplicati.Library.Utility.Utility.<EnumerateFileSystemEntries>d__20.MoveNext()
2019-11-10 01:25:58 +01 -

It also reports
System.IO.DirectoryNotFoundException.

So it seems to be a long file path problem under Windows.

For Windows 10, recent versions, launching regedit and setting
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled from 0 to 1 and rebooting fixed this issue for me.

Insert the usual warning about editing the registry.