Is there any way of using the disable-filetime-check instead of for an entire backup set but for a particular file or file(s) in the set?
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 don’t think you can do this per-file, but you can do it for a backup of all the files needing it.
Basically, if you want some files one way and some the other, how about two backup jobs?
Different backup jobs is ok to a point, but you need to then remember to exclude the files in one job, add them to another and then run both. Restoring files then needs to 2 jobs.
It would be nice for all of this to be combined to one job, with the exceptions for the time check set within that job.
I understand that some manual config will be required to add an exception to which files need to have the disable-filetime-check added but it feels like an easier solution that multiple backup or restore jobs?
It’s not easier because it’s not there. Would you like this to be a feature request?
There are more features than can be done, but maybe someone else wants this.
Yeah I think a feature request would be good. I think it would be a great addition and in my case, and a few others after looking over the forum, it would definitely help speed up my backups as I only need the disable time check for a couple of files out of loads of files in a set.
Changed topic from Support to Features category.
I think this makes sense. I know some applications do not set the timestamp by design (encrypted containers, etc).
In this case it would make sense to have a filter-like expression, something like --disable-filetime-check-include=*.iso.
Feel free to create an issue for this:
Yeah, thanks!
That’s exactly it, if certain files are done like this by design, it would be nice to disable the time check just for those and not the whole set.
This way, they will still get backed up/checked on every run, but the backup will be a lot quicker as everything else doesn’t need to be checked again.
I’ve created the issue as requested, thanks for considering this.
but as it turns out, there was this one a few days earlier. I don’t know if it was forum-inspired.
1 Like
Oh yes, sorry I didn’t see that.
Hopeful the feature will be considered as it seems like a few people may benefit from it?
I’ve run into the same issue before. Unfortunately, there isn’t a way to apply the disable-filetime-check to just certain files; it affects the entire backup set. What I did to work around it was split my backup into smaller sets, so I could apply it only to the one containing the files I needed. It’s not ideal, but it worked for the situation I was dealing with.
1 Like
One use case for this option are legacy XLS (Excel files).
When you open them in Excel, even close them without saving anything, Excel seems to be updating certain metadata inside the file but keeping the file’s changed time intact.
Here’s the (Archived) Microsoft KB describing this weird behaviour: Excel changes Modified date and time when you open the workbook
In practice, the impact is relatively minor as only the aforementined metadata is lost when restoring from backup, but if we can solve it with a parameter that allows to force backup all *.xls it would be great.
Isn’t this a reverse weird behavior of changing the time unexpectedly?
Your case is lack of change, despite possible changes to the contents.
Have you tried looking for information on that, or compared both files?
If something changed in the new file, fc /b should make some noise
although I wouldn’t expect it to be readable – just looking for presence.
Using a tool to get a hash of before versus after would be another way.
Mostly, I’m puzzled by that citation (from 2008) which seems reversed.
Testing with current software might be a better guide on need to worry.
Hi ts687
Yes, I tried. I confirm: you just open the XLS file (note: XLS – the legacy format – not XSLX – the new format) in a very recent version of Excel, closed it without changing anything and without saving, yet it modified a few bytes in the file without updating the modification date in the file system. I could see in Winmerge the few changed bytes, and obviously the file checksum is also changed.
If I do the same thing on the newer format (XLSX), then things work as expected (the file is not updated).
Indeed, this issue only applies to legacy file format that probably nobody should be using anymore. But if you still have those old files lying around, and you open them just to view their contents, then they get updated and not backed up by Duplicat.
A good workaround would be to have the --disable-filetime-check-include=*.xls feature described in Disable time check on a per file basis · Issue #5527 · duplicati/duplicati · GitHub .
Another option would be to detect changes at a lower level (= block level). I’ve seen corporate backup solutions do that either at OS level (VSS snapshots tracking changes vs the previous snapshot) and at Hypervisor level (VM snapshots using change block tracking), but it would be super complex to implement, and I’m not sure how it would fit with Duplicati’s development roadmap.
Cheers,
Gaston