Were you able to see that in Windows somehow? I couldn’t think of a nice way, which is another reason I was hoping there was Linux around (even with BusyBox commands, but I think some Synology systems do better).
If you have solved the above, you could try a –log-file with –log-file-log-level=Verbose (if Duplicati is current), which would show all the pathnames as Duplicati considers them. Maybe that will show something interesting. Some of the processing (I’m not sure of details) is asynchronous, but with luck the warning will be inserted in some reasonable place, and you can see the sequence of files/folder processed before it (and maybe after).
If you’re directly on the NAS, you could try some commands below. I’ll give both single-letter and long options.
ls --escape
ls -b
A plain ls command can be piped to
cat --show-tabs --show-nonprinting
cat -T -v
and then you could pipe to `fgrep ‘^’ to look for a caret, which I’d think would otherwise be very rarely used.
Although on the surface, this seems to be an issue in the top folder, you could inspect everything if you do
ls -R
ls --recursive
egrep has character classes, if you want to try those
The less viewer might also be handy. I’m not sure what on Windows works easily. Hex editors are awkward.
Windows Subsystem for Linux or Cygwin might be too much to ask, but can inspect NAS files from Windows.
I’ve seen varied information on illegal characters, but control characters are sure, and some of <>|":*?\/
Linux is much more tolerant of characters, which is maybe how it’s possible to get in illegal character issues, especially if direct Linux access is allowed. If the only way into the NAS is Windows, then I’m more puzzled…
Duplicati isn’t directly testing characters, or triggering that error. It’s simply passing along what .NET gave it. Possibly we can figure out what it’s seeing, either through our direct inspection, or in the log of what it sees.