Thanks a lot! Following this Downgrading / reverting to a lower version now my duplicati (2.0.3.5_canary_2018-04-13) is working again and I’m looking foreward to the next update.
SMichel
I downgraded/reinstalled 2.0.3.5 after 2.0.3.6 was not working properly. Luckily the backups are running like normal again although missing several days worth of backups meant the backups are taking much longer than a normal daily backup does.
Just as an FYI it appears 2.0.3.6 has introduced a bug causing SizeOfAddedFiles
and SizeOfModifiedFiles
to always be 0.
Good morning.
I’ve installed the latest canary version 2.0.3.6. of Duplicati on Linux Centos6.
Wonderful software!!! I’ve installed it other times on WIndows, and everything is ok.
But I’ve notice that on Linux the Log has something wrong. Infact SizeOfAddedFiles is always zero:
DeletedFiles: 629
DeletedFolders: 0
ModifiedFiles: 0
ExaminedFiles: 38372
OpenedFiles: 1341
AddedFiles: 1341
SizeOfModifiedFiles: 0
SizeOfAddedFiles: 0
SizeOfExaminedFiles: 14864698389
SizeOfOpenedFiles: 699…
It has already been reported on GitHub.
opened 04:35PM - 08 May 18 UTC
closed 10:23AM - 19 Jun 18 UTC
- [x] I have searched open and closed issues for duplicates.
----------------… ------------------------
## Environment info
- **Duplicati version**: 2.0.3.6_canary_2018-04-23
- **Operating system**: Debian Stretch
- **Backend**: WebDAV
## Description
Since the update to 2.0.3.6, Duplicati always reports `SizeOfModifiedFiles` and `SizeOfAddedFiles` as 0 to the HTTP reporting (`send-http-url`).
I have experienced this with one Debian Stretch Linux system of our own. Moreover, I have checked reports received at duplicati-monitoring.com and found an significant increase of backup reports that show 0 modified/added size, but more than 0 modified/added number of files starting 24.4.2018 - one day after the release. Thus, I assume other users are also affected.
## Steps to reproduce
1. Update to 2.0.3.6 (Canary)
2. Configure `send-http-url` for a backup
3. Change/add some file that will be backed up
4. Run the backup
5. Check the POST request that Duplicati sends
- **Actual result**:
For example, I get the following report:
```
Duplicati Backup report for XXX
DeletedFiles: 1290
DeletedFolders: 0
ModifiedFiles: 1783
ExaminedFiles: 53115
OpenedFiles: 3475
AddedFiles: 1692
SizeOfModifiedFiles: 0
SizeOfAddedFiles: 0
SizeOfExaminedFiles: 57109512282
SizeOfOpenedFiles: 40305089551
NotProcessedFiles: 0
AddedFolders: 0
TooLargeFiles: 0
FilesWithError: 0
ModifiedFolders: 0
ModifiedSymlinks: 0
AddedSymlinks: 0
DeletedSymlinks: 0
PartialBackup: False
Dryrun: False
MainOperation: Backup
ParsedResult: Success
EndTime: 08.05.2018 12:31:36 (1525775496)
BeginTime: 08.05.2018 11:36:32 (1525772192)
Duration: 00:55:03.9215230
```
- **Expected result**:
SizeOfModifiedFiles and SizeOfAddedFiles should be greater than 0, as at least one file was modified in step 3.
## Screenshots

This is a screenshot of a diagram generated by duplicati-monitoring.com showing
- SizeOfModifiedFiles (in blue)
- SizeOfExaminedFiles (in green)
- SizeOfAddedFiles (in gray, almost no new files in this case)
You can see that no files seems to be added or modified since 29.04.2018. Anyway, the sizeofExaminiedFiles increases. This is not possible. If the data that is being backed up increases, then some non-empty files must have been added or modified. I have checked the raw reports that Duplicati sends, it is not the duplicati-monitoring parsing them incorrectly, the 0 can be found in the reports (see example above).

This graph shows the significant increase of backup reports received at duplicati-monitoring.com that have zero modified/added data but more than zero modified/added number of files.
Note that it is always possible that files are added/modified and the size does not change, if empty files are being added. This is why there have been reports like this before.
## Debug log
1 Like