In Duplicati v1 I can see what files was added to backup by right click and choose “View content…”.
Now I see only backup size and number of versions, but I can’t see what file be added or changed (of course: all blocks of file was added or at least one) or deleted or didn’t changed and when. It’s very useful information.
Thank you.
In Duplicati 2, you can use the compare command to view the difference of any 2 backup versions.
commandline.compare.1
0
--full-result
This will compare backup version 0 (latest backup) with backup version 1 (backup before latest). The --full-result option will list all new, changed and deleted files. Without this option, only the first 10 files are listed.
Big thanks. But do you have a plan to do such feature to UI?
Lots of plans, not so much time to actually do it 
Just FYI, with 2.0.2.1_beta_2017-08-01, that command line operation resuts in a sqlite exception for me.
Strange. I have no problems using the same version.
The compare command doesn’t require the local database, so what happens if you remove all advanced options? (quick and easy way is to switch to advanced view. All advanced options are listed in a text box. Select all options with ctrl+A and del).
I found the cause of the sqlite exception. My backup job has a couple of “exclude” entries in the advanced options. If I delete those exclude options in the commandline screen, then the compare operation runs successfully. Thank you kees-z.
I just tried this with version 2.0.2.19_canary_2018-02-12, and the sqlite exception does not occur even if the “exclude” entries are present. It appears that this issue was resolved sometime after version 2.0.2.1_beta_2017-08-01.
I found problem with this solution. If no changes in latest backup, it is comparing previosly changed backup with prev prev backup. How do I know if files were added, deleted, or modified during the last backup?
I want to e-mail or create log via “compare” only if backup changed when I use “run-script-after”.
Interesting, when I run the compare command, I see a lot of folders being mentioned as Modified entries even though no files inside those folders are listed or changed.
I see the same when running compare against another backup target.
What could be causing this?
I think folders metadata was changed.
Any change in timestamps or permissions. For example, adding and deleting a file is two timestamp changes – one on the add, and one on the delete, yet if it happens between backups, file isn’t there.
Example of adding and deleting a file:
Listing changes
1: 3/3/2024 7:54:53 AM
0: 3/3/2024 7:55:41 AM
Size of backup 1: 101 bytes
1 modified entries:
~ C:\backup source\sub1\sub2\sub3\
Modified folders: 1
Size of backup 0: 101 bytes
Return code: 0
Beyond that it becomes an OS and usage question, and none of that was detailed. On Windows, the Sysinternals Process Monitor tool can watch a given folder, if you can’t otherwise find change cause.
I see I forgot to mention something important. These folders are listed in almost every backup. I have compared backup 0 to 1, but also 1 and 2, 9 and 10 and some more.
One thing I just realised is that these folders are also being synced to Google Drive. Could it be that that process changes metadata of the folders?
This is on Windows 10 by the way.
Which option? See below which is not the default, costs me speed and space, but has benefits:
EDIT:
Explorer will let you right-click the column headers. For example turn on Attributes for a look.
This may be a little easier than the Command Prompt attrib command, but that can also help.
I’ve set it up to Mirror files. I’ve set up several folders to be synced to Google Drive.
I’m not sure though, I have a folder on my computer that shows up as Google Drive (G:). But I’ve also set up Google Sync to backup several folders from my Z: drive. So for instance, my folder named “CV” is set to be synced to Google Drive. And this is one of the folders I see listed when running Compare on Duplicati.
I’ve set Windows Explorer to show me all date attributes for this folder, but all dates are in the past. I know for sure that I haven’t used any of the files in this folder for months.
You didn’t turn on Attributes as below, although that’s worse with Stream.
Duplicati team doesn’t produce or have inside knowledge of Google Drive.
Is this causing an actual problem? Deep investigation is possible but hard.
Best approach is a small test case, then dig into database and dblock files.
EDIT 1:
Here’s what a metadata block looks like. If you do a small enough test case,
you can avoid the database and just look at what’s found in dblock .zip file:
{"win-ext:accessrules":"[]","CoreAttributes":"Directory","CoreLastWritetime":"638450906623020088","CoreCreatetime":"637864905012476411"}
If Duplicati says folder changed, you can compare such before and after data.
This has things like ACLs, attributes, and times at 100 nanosecond resolution.
EDIT 2:
Or if database is easier, you can look in File view at the MetadataID column.
If your Path keeps getting new MetadataID, then something in there changed.
Duplicati only records what’s there, and it’s out of scope to say why it changed.
EDIT 3:
You could also try to look for a pattern. Are all folders seen modified? Some? What might influence?
EDIT 4:
I can see something like this if I pick the right backups. If I look with Sysinternals Process Explorer at GoogleDriveFS.exe start times, the last weirdness was in backup after the parent replaced children.
Perhaps you could do the same analysis, however if it’s what Google Drive does, we may be stuck…
I don’t have the whole run history of GoogleDriveFS.exe, so it’s speculative until someone can check.
EDIT 5:
Experimental method used the single-number form of compare, which compares to latest, which is 0.
Giving 1 went fine. Giving 2 moved to before the time of the GoogleDriveFS.exe launch and was bad, meaning lots of folders had different metadata, making me wonder if the new launches changed data.
Possibly I can find some actual metadata (example shown above) to see how Google Drive leaves it.
EDIT 6:
The metadata block is very ordinary, however the CoreLastWritetime is roughly when Google Drive came up after reboot for Windows update. What’s odd is that Explorer shows it around its child starts.
Looking at C:\me\My Drive shows lots of top level folders there have got their Date modified then.
I’m not sure there’s any way to fix this. It appears to be a Google Drive behavior that throws things off.
Notes above. To add some more, here’s a Process Explorer display with start times and version bump, although the last process didn’t have a new version. This system has been up since the Feb 15 reboot.
I set this up to see what would happen. Maybe it was a little different than yours, but Google Drive quit from its menu changed the Date modified visible in Explorer, but it’s imprecise, so I used PowerShell
PS C:\> (Get-Item "C:\backup source\CV").LastWriteTime | Select-Object *
DateTime : Monday, March 4, 2024 8:27:33 PM
Date : 3/4/2024 12:00:00 AM
Day : 4
DayOfWeek : Monday
DayOfYear : 64
Hour : 20
Kind : Local
Millisecond : 915
Minute : 27
Month : 3
Second : 33
Ticks : 638451808539151273
TimeOfDay : 20:27:33.9151273
Year : 2024
I did another backup, opened up the dblock to see what timestamp it picked up, and found the below:
{"win-ext:accessrules":"[]","CoreAttributes":"Directory","CoreLastWritetime":"638451988539151273","CoreCreatetime":"638451973581119934"}
Watching the folder with Process Monitor found GoogleDriveFS.exe all over the folder when I did quit. Unfortunately, I didn’t find an operation lining up precisely in time with the 100 nanosecond time I had.
About all I can say is Google Drive changes folder timestamps. Google search found other posts, e.g.
Google Drive changing modified date / time for synced folders on hard drive