Invalid Win32 FileTime


On 18 of the 8086 files I’m trying to backup I get the following warning (replaced actual path by …):

Failed to read timestamp on "D:\...\...\...\...\sp2006014.doc" => Invalid Win32 FileTime.
Parameter name: fileTime,

As far as I can see there’s nothing wrong with the timestamp of those files. I tried to resolve it by changing the .doc file and saving it again but that didn’t help. Is there anything else I can do to get rid of these warnings?

Best regards,

I had it for coupe files - but always with some reason, for example:

Maybe @p_vestjens try chkdsk? Or put them in zip archive ?
I end up with excluding those file from backup

I’m curious - were the files backed up anyway, just with a warning or did they not back up at all?

The Modified timestamp of these files is empty somehow, as is visible in the Explorer view below:

I ran chkdsk but that didn’t help.

I think they are backed up. I tried restoring one of them and I had a choice of various versions so that seemed okay.

Since the original issue is just a warning then yes, the backup should have worked as expected.

But that leaves me wondering if we should silently catch this warning or make it informational. If so, I assume a similar catch would have to be made during restores of files with invalid date/time stamps. What do you think @kenkendk - if the file is backed up and there’s nothing Duplicati can do to resolve the issue, what’s the point of making it a warning that will never be resolved?

If you’re up for a test, trying running a backup (could be test one to a local folder that just includes those “bad date time” files) with the --skip-metadata parameter.

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”

I also feel that the warning is a bit too alarming (see picture below). IMHO, if it does not affect the functioning of the application then it is not necessary to alarm the user. Better reserve those warnings in red to trigger the user to take action.

I tried this but it did not help. I set the configuration as shown below:

Yeah, the --skip-metadata thing was a long shot. Since it’s the actual file modified date that Duplicati uses to check for file changes (rather than “extended” metadata) I guess the parameter doesn’t help.

As a second test (again, not a fix) can you try setting --disable-filetime-check = true? This will likely increase your backup time but should avoid that error.

--disable-filetime-check = false
The operating system keeps track of the last time a file was written. Using this information, Duplicati can quickly determine if the file has been modified. If some application deliberately modifies this information, Duplicati won’t work correctly unless this flag is set.

I suppose for an empty modified timestamp (as seen in @p_vestjens image above) we could “coalesce” to DateTime.MinValue. This wouldn’t help with @mr-flibble’s year 30826 issue but it would be a start.

The drawback is that a restored version of this file would have a different timestamp than the original. Is that something we’re OK with? Alternatively, we could use .MinValue as “special” to mean don’t write any modified date (if that’s even possible). Of course I’m assuming there are more files with empty modified dates than a date of midnight on Jan. 1, 0001…

Well… That depends on what the user expects. If the user expects the backup to be restored exactly like the source (including timestamps), they really do need the warning.

Also, the missing timestamp does cause performance slowdowns as the files need to be scanned when the modification timestamp cannot be read.

@p_vestjens I think the quickest solution for you is to simply set the modification timestamp on the files. There is a post describing how here:


I finally came around chaning the modification timestamp on the remote machine using an open source touch utility. The warnings are now gone.

Thank you!

1 Like

Good to hear!

I went ahead and flagged your post as the solution (even though it’s more of a workaround than a fix). Please let me know if you disagree.