Thanks. And are there still unique issues of running Duplicati on Synology?
Not really, I just like the idea of using docker!
I only had one issue with the native Synology package but was able to work around it: Duplicati does not auto start.
I think this may be a dependency/timing issue on NAS bootup. The Mono package may not be started first, so Duplicati fails to start. (This is just speculation.)
Someone else in the forum showed me how they used the Synology Task Scheduler to launch Duplicati. You can create a task that is triggered at the ābootupā event. Using a bash script we can introduce a 1 or 2 minute delay to ensure Mono is started first, then launch Duplicati.
Some problems with this approach - there isnāt a clean way to shut down Duplicati. I have to ssh to the NAS and send a SIGTERM to the process using the kill command.
An advantage to this Task Scheduler approach is that I can pass custom command line options to the Duplicati process - something that seems to be impossible with the native Synology package.
On Windows I get matching values and with milliseconds.
I have a Synology I can test on.
Theory, but please confirm mono --version is still per below (from July 26, 2019). Docker mono is newer.
Added support for nanosecond resolution in file information on platforms where the information is available. This means the return value of APIs like
FileInfo.GetLastWriteTime ()is now more precise.
Synology seems to use btrfs or ext4. Both have nanosecond resolution. Use stat command to see it.
Great, would love to hear your results. Iām poking around the sqlite database created by the Synology Duplicati package and it looks like this:
Great catch! Yes, the Mono Synology package is still version 4.6.2. I think you solved the mystery!
Great find! That does explain what is being seen.
Should Duplicati compare down to the nanosecond though? or just millisecond?
I think it should support whatever the underlying API and filesystem support.
Iād hate to dumb down Duplicati - even though it may have solved the āfalseā need to reprocess my files, reducing resolution could cause it to not back up a legitimately changed file. (As unlikely as that event may beā¦ a file would have to be modified within a fraction of a second of the previous backup/snapshotā¦)
The mono 4.6 issue aside, I think weād want to have time comparison be equal between platforms for portability. This may no longer be an issue once weāre on .net core.
But at least we know that all users are going to see this behavior when they upgrade mono given the current compare.
Good pointā¦ definitely worth some thoughtā¦
Iām not sure it had millisecond on the old mono. Interpreting trailing zeros as seen on Lastmodified image:
7 is 100 ns
6 is 1 us
5 is 10 us
4 is 100 us
3 is 1 ms
2 is 10 ms
1 is 100 ms
0 is 1 s
The first timestamp of the image evaluated at https://www.venea.net/web/net_ticks_datetime_converter:
Portability meaning what? Thereās both mono version issue and filesystem issue (FAT32 is 2 secondsā¦). Thereās also a question of restore accuracy if (for example) times are rounded to some approximate time.
The idea was given in the target framework upgrade that an in-spec system would follow the manual, and install latest from mono-project (unless they canāt, e.g. Synology). SynoCommmunity has v5.18.0.240-12.
https://repology.org/project/mono/versions shows that (ignoring mono-project for now) distros that got v5 generally got v5 beyond v5.12.0, so possibly the majority of users are past danger point (and not noticing).
Survey for Linux users, which version of Mono do you have installed? isnāt a random sample, but got data. The impact of the problem āshouldā be rescans and a relatively small upload for the new metadata blocks. Personally, I favor Duplicati doing what it can within its limits and without attempting to dumb things down.
This is getting far from the original topic, so maybe discussion can go elsewhere now that itās understood.
For what itās worth, I have a synology as well and see this behavior sometimes as well. Will try to remember next time what could have triggered it.
On experimental, not sure which mono. Will check later.