Duplicati is a cross platform tool and as such get a different metadata blob for each of the supported systems (Win, Linux, Mac). The modification date is extracted from the metadata by the .NET engine, but the rest is as I said a blob and trying to interpret it is not so obvious. As of changing the basic behaviour for a date because of a problem that may be caused by a bug in a specific software on a specific platform (I don’t think that Samba is anything like a dominant backend for Duplicati), it’s not a very appealing idea anyway.
Looks suspicious to me. It’d be hard for that to be coincidence. If it keeps moving, see if pattern holds.
I’m not sure, but it could be tested (or maybe code dug through). This is just a trigger change. It’s not:
--skip-metadata (Boolean): Don't store metadata
Use this option to disable the storage of metadata, such as file
timestamps. Disabling metadata storage will speed up the backup and
restore operations, but does not affect file size much.
* default value: false
if you change metadata on a file when this flag is on, nothing will be backed up and the change in attributes for example will not be recorded on the backend.
and if you get the typical timestamp change, then data and metadata are backed up?
Guessing so, but haven’t tested, just saying it’s not the same as no metadata at all…
Possible result (maybe good here) is it drops bogus changes, but records valid ones.
This is all tentative because we’re still looking into nature/source of bad creationtime.
A workaround might be appropriate, because this appears to be external to Duplicati.
The above-mentioned post at Ubuntu is going all over from SMB version to kernel, to
specific NAS vendor implementations. Getting in deep there, and still not understood.
One person thought that SMB version made a difference, and looked in /proc/mounts.
Windows equivalent might be Get-SmbConnection, and see what Dialect was chosen.
Controlling SMB Dialects gets deep in internals, but rather than risk Windows, maybe
smb.conf server min protocol and server max protocol could limit what Windows uses.
The MS deep dive also used Wireshark, and that might narrow down the causes here.
In simple work, it looks like creationtime.ticks can use human-friendly timeofday.
if it’s a ‘typical’ timestamp change, it is the operating system recording a data change, so yes, it will trigger a backup of some data. If it is only the timestamp changed (a file hack by the user for example), it will not trigger any backup of real file data since Duplicati deduplicates.
What is this filesystem? It apparently can record nanosecond precision, but not file creation time, however there were lots of components (including kernel) to change to align to get that capability.
Possibly (grasping at straws), a change of filesystem (likely hard) or a system update would help. Alternatively see if the suggested workaround works. Duplicati team can’t solve all system issues.
This seems to have worked. Log now says Skipped checking file, because timestamp was not updated, and the file is not listed in the modified files count, or in the output of the compare command. The backup time has also dropped significantly, likely because the files are actually being skipped and not re-read. I’m going to keep this as my standard backup option now, and will post an update if anything changes. Thank you!
ext4. Using lvm to span 2 physical drives, not sure if that makes a difference.