The only Netware queries in this forum or GitHub Issues are yours. I sure have not run it.
The rareness of Netware unfortunately brings increased difficulty in trying to provide help.
Thank you for providing further details on testing below.
The only files whose data would be read are ones whose timestamp or attributes changed.
I don’t know if attempting to get file metadata requires Netware to decompress the file first.
Possibly you can draw conclusions by seeing what files get read compared to file changes.
This part I was able to get from Google search, but I didn’t manage to find it doing timeouts.
Further, the lead author said above that no timeouts are managed by Duplicati. It just reads.
This is blaming a lot on a timeout, including extended attribute issue we’re discussing more.
Process Monitor should have a lot of time stamps. I can’t see the timing from a single query.
What would such an error look like? That output is hard to read.
Duplicati has no knowledge of or direct call to any remote storage server. You configured it as
Local folder or drive and it is treated as such, and expected to work. Yours is not working well.
Problem could be in .NET (as you said one time), Windows, or its installed driver for Netware. Tentatively I’ll say that your checking on the server seeing no errors suggests client-side error, somewhere below Duplicati where we have little to no ability to diagnose beyond what you did.
Too vague, but yes it stores status of many things in many places. It also offers (too many) logs detailing activity at the Duplicati level. It does not and likely cannot record what happens below, which is out of scope for an application program, and out of scope for Duplicati support as well.
A stack trace is sometimes possible and at least makes it easier to find the trail inside Duplicati. Detailed logs (but not beyond Duplicati) can be made with log-file=<path> and log-file-log-level probably raised some. If not used, Warning is the default. That might get a bit more information. Verbose will start talking about source files. The below is About → Show log → Live → Verbose which is reverse chronological. The log-file is chronological, has seconds, and runs unattended.
Oct 22, 2024 12:12 PM: File has changed C:\backup source\short.txt
Oct 22, 2024 12:12 PM: Checking file for changes C:\backup source\short.txt, new: False, timestamp changed: True, size changed: True, metadatachanged: True, 10/22/2024 4:12:04 PM vs 10/22/2024 4:09:34 PM
Oct 22, 2024 12:12 PM: Including source path: C:\backup source\short.txt
Profiling level gets extremely long and is aimed at SQL work. There’s an option to make it bigger.
I’d probably start with Verbose, as you care about file paths. Name may show up at different time locations because there is asynchronous processing at work doing the different pieces of backup.
If you make a huge log file, use your favorite huge log file viewer. I use glogg on some huge files.