I guess you can put the big Process Monitor file somewhere, and PM a link. Or look at it yourself. Tomorrow, my schedule is a little unknown, plus we’re at the point where the study may get deep.
One question I have is whether Duplicati stopped looking at files. We know it kept enumerating…
Verbose log showed that, but either it found nothing changed later (any forecast?), or didn’t look.
Silence isn’t too informative, but Process Monitor should be nice and loud. A look involves things
such as timestamp, and metadata such as security attributes. My re-backup without change said:
2:41:20.7175998 PM Duplicati.GUI.TrayIcon.exe 34156 31100 QuerySecurityFile C:\tree\000000\000000\000005\000008\000002\000005.txt SUCCESS Information: Owner, Group, DACL
which might be getting the security attributes from NTFS. There were a lot of queries looking like:
2:41:20.7141987 PM Duplicati.GUI.TrayIcon.exe 34156 143180 QueryNetworkOpenInformationFile C:\tree\000000\000000\000005\000008\000002\000005.txt SUCCESS CreationTime: 3/10/2021 12:25:26 PM, LastAccessTime: 3/10/2021 12:25:26 PM, LastWriteTime: 3/10/2021 12:25:26 PM, ChangeTime: 3/10/2021 12:25:26 PM, AllocationSize: 0, EndOfFile: 0, FileAttributes: A
but this is below where Duplicati devs usually probe. It’s below .NET Framework, deep in Windows.
If you want to look, you don’t need to know the detail either, just look for names seen in Verbose log.
Above was from a Process Monitor filter like the below, but you can also just scroll and study names.
Filter approach went well with my profiling log, which is another long-output option we could attempt:
^2023-12-12.*C:\\tree\\000000\\000000\\000005\\000008\\000002\\000005.txt
regular expression in log viewer (glogg in this case, but there are other ways to view files), said this:
2023-12-12 14:41:16 -05 - [Verbose-Duplicati.Library.Main.Operation.Backup.FileEnumerationProcess-IncludingPath]: Including path as no filters matched: C:\tree\000000\000000\000005\000008\000002\000005.txt
2023-12-12 14:41:20 -05 - [Verbose-Duplicati.Library.Main.Operation.Backup.FileEnumerationProcess-IncludingPath]: Including path as no filters matched: C:\tree\000000\000000\000005\000008\000002\000005.txt
2023-12-12 14:41:20 -05 - [Verbose-Duplicati.Library.Main.Operation.Backup.FilePreFilterProcess.FileEntry-SkipCheckNoMetadataChange]: Skipped checking file, because no metadata was updated C:\tree\000000\000000\000005\000008\000002\000005.txt
Channel Pipeline is a developer-level view of the work, but you can see in timings that enumeration is getting a few seconds ahead of the deeper peek. It’s also a little strange to see file enumerated twice.
This is just a random file I got out of a re-backup that would look through all files and find no changes:
For your backup, the verbose log shows files after the seeming stall, but are there changes in those?
If it weren’t for the count not going down, staying on the last file with changes is quite a normal “view”.
My backup stays still like that all the time, but its count goes down while it’s looking for next change…