File Modification Times on BackBlaze B2

[dscotl]

Greetings!
I am confused on whether B2 / Syncovery support preserving file modification times. I see in the list of features that:

'Advantages of using Backblaze B2 with Syncovery
B2 is a high-reliability and high performance storage
...
You can set up multiple jobs with extreme customizeability, including:
File Masks & Filters
Compression, Encryption, and Filename Encryption
Multithreaded Transfers
File List Cache can avoid re-scanning the B2 folders every time the profile runs
Manual, scheduled, or real-time operation
One-Way or Two-Way Syncs
SmartTracking for Two-Way Syncs can detect deleted files and you can use B2 as central repository for sharing files between several computers
File timestamps are preserved on B2

However, when I create a profile to store to B2 I get the warning that file modification times are *not* preserved and that I should use Filename Encoding. Also, I see on BackBlaze's documentation that metadata for preserving file modification times are supported.

I would like to be able to sync files to B2 and have the original file modification times preserved without filename encoding so I can work with uploaded files on B2 from programs other than Syncovery.

What am I missing?

Cheers!
~Scot

[superflexible]

Hello,
if you have the latest version 7.98 of Syncovery (or 8.00 beta), then timestamps will be preserved without the need for Filename Encoding. If you get this message, please ignore it.

[dscotl]

I am using the 7.98b version now. I am not getting the warning message. However, it is not clear to me the uploaded files are preserving modification times. How can I verify this? When I view the uploaded files on the BackBlaze web interface I only see the upload time. In the detailed properties for the uploaded file the onIy property I see that seems to references the file modification time looks like this:

File Info: src_last_modified_millis: 1433364978 (01/17/1970 08:09)

The 1970 date is clearly not correct -- is there another interpretation of this value?

[superflexible]

Hello,
you can verify by running the Syncovery job again and looking at the Sync Preview. It shows the timestamps for both sides. Click on "Show All" in the top left corner to see all files, even those that do not currently need to be copied.

[dscotl]

I do see that Syncovery interprets the file mod time correctly and I can restore files with the correct mod time.

I was hoping Syncovery was using Backblaze in a fashion that would expose the file mod time to the Backblaze file browsing function and expose the file mod time to other applications that I might need to interoperate.

For instance, I'd like to be able to give iPhone/Android users access to the B2 store from third-party apps and have the file mod time be correctly displayed.

In another instance, I have a Synology NAS that has an extension (CloudSync) that can sync to B2 and I'd like the NAS to get the correct file mod times when it syncs to a B2 store that was uploaded (is sync'd) from Syncovery. In this instance I'm wanting to do two-sync between a main office and a satellite office.

It appears the src_last_modified_millis attribute in B2 is being overloaded to actually contain the number of *seconds* since 1/1/1970@00:00 rather than the number of *milliseconds*, causing BackBlaze to interpret the mod time differently than Syncovery. I am curious why this was done this way.

[superflexible]

Hello,
wow, that's a bug that even the B2 team did not catch. Many thanks for the report.

I am working on an update that fixes this, while also interpreting the existing values in a backwards compatible way.

[superflexible]

The new version 7.98c fixes this now. Syncovery will recognize both the old timestamps (based on seconds) as well as the correct ones (based on milliseconds). It will not fix the timestamps for existing files on B2 though.