The support forum

Created file timestamps not supported by source

dench :

Jan 09, 2019

Hello guys!

I am new to the forum and I am currently evaluating Bvckup2 for my new backup strategy.

The test backup scenario is as follows:

I have a PC running Bvckup2, a Synology NAS with DSM 6.x and an USB drive attached to the NAS and exposed as a shared folder by the NAS.
USB drive is NTFS, NAS is accessed via SMB. Both USB drive and NAS are mapped as network storage in Windows 7.

I have a test folder Source_fldr, that I want to copy to Target_fldr with preserving both c-dates and m-dates (created/modified).

The current result is, that c-dates are not set to their original dates but to now().

I tried to play arond with the recommendation from here
bit unfortunately without success.

The same scenario ran with alternative software runs OK, but the alternative has some other issues, so that Bvckup is my favorite tool by now.

Investigating the problem I found in the log following entries:

Deducing changes ...
    File system information
            Device : remote share, over SMB 2.1.0
            Type : NTFS
---> Created timestamps : NOT supported
            Modified granularity : 1 sec  ( 1 sec probed, 100 ns deduced )
            Supported attributes : hidden, system, archive
            Supported API mask: 0x0d
            Volume : flags 00010027, serial xxxxxxxx
                Encryption: NOT supported
                Compression: NOT supported
                NTFS streams: NOT supported
            Device : remote share, over SMB 2.1.0
            Type : NTFS
---> Created timestamps : supported
            Created granularity : 100 ns  ( 100 ns probed, 100 ns deduced )
            Modified granularity : 100 ns  ( 100 ns probed, 100 ns deduced )
            Supported attributes : read-only, hidden, system, archive
            Supported API mask: 0x0d
            Volume : flags 0005002F, serial xxxxxxxx
                Encryption: NOT supported
                Compression: NOT supported
                NTFS streams: supported
    Timestamp granularity
        Created: 1 sec
        Modified: 1 sec
    Preparing backup plan ...
--->    Source does not support "created" file timestamps
        These timestamps will not be copied
        Planner setup
            Created timestamps: (not supported)
            Modified timestamps: compare and update
            1-hour offset: disabled
            Update folder timestamps: yes
            Preserve newer files: off
            Attributes: read-only hidden system archive
            Security info: don't compare, don't update
            Alternate streams: ignore
            Clone top folder info: no
            Files to ID: new
            Move detection: folders, files (by name/size/times, by file ID, by fuzzy matching)
            Disable deletes: no
            Archive deleted: yes
            Archive modified: no
            Precomp delta: no
        Completed in 1 ms

I also found the topic about similar problem with the destination,
but in that topic I haven't found a solution about my problem. Any hints?

Thanks + cheers!

dench :

Jan 09, 2019

Sorry, forgot to mention:
<Source folder> is on the USB drive, the <target folder> is on the NAS.

Alex Pankratov :

Jan 09, 2019

The culprit is this:

Deducing changes ...
    File system information
            Device : remote share, over SMB 2.1.0
            Type : NTFS
---> Created timestamps : NOT supported

If the program thinks that either side doesn't support created timestamps, it doesn't clone them from source to the backup.

The way it understands if these timestamps are supported is by creating a temporary file at each location and then running some tests with it. In your case an attempt to set created time on that test file failed one way or another.

You can get details from the file system testing log -


The failure will be recorded between these two lines:

        Running active tests...
=>   xxx
        Created times: 0

Let me know what you find there.

File system is tested once and the results are cached. It is however re-tested every time the job is started manually with Go ** and the CTRL is held down **. Make note of this, because it's important for the later.


Now, you CAN work around this and force the copying of created timestamps. This is done by adding the following override to the job's config file -

        filesys.src.ctime   1

See here for how to do that -


Finally, keep in mind that any override is used only when the job is loaded at program's start. This is where manual Ctrl-Go starts become of relevance - these will force file system re-test and will discard the override until the next program restart. That is, if need use them, use with due care.

dench :

Jan 09, 2019

Ok, let's figure it out:

On a 1st attempt I changed the destination dir and set to rescan destination in order to have a "clean, initial run". This brings the following in the log:

19:12:44.375  File system:   NTFS
19:12:44.375  Volume flags:  00010027
19:12:44.375  Timestamps:    1 1 (assumed)
19:12:44.501  Running active tests...
--> 19:12:44.549  Created times: 1
19:12:44.725  Attributes:    00000026 00000026
19:12:44.735   times > 131915311111111111 131915311111111111
19:12:44.739         < 131915311119999999 131915311119999999
19:12:44.739  Special case of Synology DiskStation
19:12:44.759  Timestamps:    10000000 10000000 (probed)
--> 19:12:44.759  Created times: overridden to 0
19:12:44.809  API support:   GetFileId    - yes
19:12:44.809                 GetBasicInfo - yes
19:12:44.809                 SetBasicInfo - yes

As you can see, "Created times: 1" is not the expected ": 0". Also, "created times: overriden to 0" sounds a bit strange to me, because no override.ini was used in that run and the job config file was set to

conf.update_folder_times                           1

On a 2nd attempt again a clean destination was selected, the delta state msg was answered with yes, override.ini was set with your proposed setting and job settings were reloaded with CTRL + right click -> Reload -> Yes. Then "Go" was executed and voila: the destination dir has the expected timestamps!

And just to get the override-logic straight on my side:

The CTRL+click / CTRL+right click and reload job settings is just to get the override in the current session without exiting the application, right?

So if I now keep the override.ini as I want to have it, the next time when I start the application the override will be automatically be activated, right?

Thanks for your support, I really appreciate it!

Alex Pankratov :

Jan 09, 2019

Ah, OK... this is one of empirical fixes for one of many Synology glitches. I don't quite remember the exact case for this one:

    19:12:44.739  Special case of Synology DiskStation
    19:12:44.759  Created times: overridden to 0

but it basically means that timestamps ending with ...9999999 were a tell-tale sign for a Synology firmware that was messing up created timestamps. So the workaround was to pretend they weren't supported.

However, this quirk has to do with _setting_ the timestamps, so the workaround should be applied only to _destination_ volumes, and not the source as it is in your case.

I'll see that we fix this in the next release, but for now please stick to the override (which will indeed be applied on every program restart).

dench :

Jan 10, 2019

I tried some other scenarios, will write them at the end of this post.

What is kind of strange: Same set of files copied from the NAS-USB drive to another QNAP NAS (luckily I have a QNAP as well ;-)) was not affected by the override workaround. I run it twice with reloading and with CTRL+Go-clicking and in both cases the copy had (the unwanted state of) c-date timestamp set to today.

After comparing the settings.ini with the text editor an putting the

filesys.src.ctime                                  00000001

in the settings.ini directly did the trick and the copy was OK.

So for my case it seems cruical to understand how I can rely on the
filesys.src.ctime                                  00000001
feature`? Can I put it directly in the settings.ini of every batch job and don't take care about the override.ini and whether it got applied or not?

Is the only difference in handling both filetypes in the feature, that "override" can be reloaded on the fly and "settings" need the application to be shut down to be entered and to be applied?

And here is the part with my other test scenarios, may be they can help you on later bugfixing not only in my case, but in general.

I used for every test the same set of files and directories and transfered them to the respective source dir with other tool, which does not have the issue with the c-dates with synology-based source dir.

So basically the scenario were replicated with
1) Synology NAS (mentioned as NAS)
2) USB drive attached to the Syn NAS (mentioned as NAS USB)
3) SSD drive in my PC in order to get around possible latency USB-based issues if Bvckup2 copies and reads just too fast from source/target, when it is testing if "c-dates are supported".
4) QNAP NAS  (mentioned as QNAP)

So the copy scenarios were:
- from NAS USB to NAS - NOK, works after applying override.ini
- from SSD to NAS - OK
- from SSD to QNAP - OK
- from NAS USB to QNAP - NOK, works after putting filesys.src.ctime                                  00000001 in settings.ini
- from NAS to QNAP - OK

It seems, that the timestamp with the 9's

19:12:44.739  < 131915311119999999 131915311119999999
19:12:44.739  Special case of Synology DiskStation

appear only when the source is the USB connected to the NAS, so sort of USB implmentation bug with Synology.
When the files are copied directly from SYN NAS to QNAP, everything is fine without any extra preparations like editing settings.ini or putting override.ini into the game.

dench :

Jan 10, 2019

Good morning everyone,

here is a post related to the observed behaviour from my previous post:

Just a quick post to advise on a file management issue that I have reported and confirmed with Synology.
It appears when copying or moving files onto an external USB drive with an NTFS file system.

The dates on the files copied to the USB drive will all be changed to the current system date - that is the creation date, the modified date and the last accessed date.

dench :

Jan 10, 2019

Hm... Another strange thing observed right now:

One and the same job (A) started over and over again into different target dirs in order to flush every time delta calculation. The job was cloned from a job, that used yesterday the override.ini and then run OK:

Toady's results of job A, copy from NAS USB to NAS:

Run 1, settings.ini was used with this setting:
filesys.src.ctime                                  00000001
override.ini was used with this setting:
filesys.src.ctime                                  1
Result: c-dates were copied wrong

Run 2, only settings.ini was used with this setting
filesys.src.ctime                                  1
Result: c-dates are correct

After Run 2 setting.ini was modified by the application and the setting became once again the preseding zeroes.

Run 3, nothing changed but the target dir, so setting.ini set after Run 2 by the application to
filesys.src.ctime                                  00000001
Result: c-dates are correct !?!

I mean, having the result from Run 1 I would expect Run 3 to be not OK?

Alex Pankratov :

Jan 10, 2019

Just wait until next release :) It will be patched properly and shouldn't require any overrides.

As I mentioned the program should switch off copying of "created" timestamps only if the program observes ...999999 timestamps *** on the backup side ***.

The issue you've run into is that right now the program also switches off "created" copying if it sees ...99999 on the source side. It should NOT do that and the patch fixes exactly this.

If all goes well, the release will go out tomorrow. Otherwise it will be early next week.

dench :

Jan 10, 2019


Thank you for fixing it. I tried to workaround this with a post-backup batch, but if it is in the application it should look and feel much more smoother.

No problem to wait for that time, thanks once again.

dench :

Jan 14, 2019

Thank you for bringing the fix that quick. First tests look good... ;-)

New topic

Made by Pipemetrics in Switzerland

Blog / RSS
Social Twitter
Miscellanea Press resources
Legal Terms