True Image 2019 changes file's date and time stamp
I use the bootable medium of True Image 2019 to backup ntfs drives (Windows 10).
I noticed the change of date and time stamps of files I never edited and their content hasn't changed either.
The change of the time stamp truly coincides with running a backup with True Image.
The weird thing is: those files aren't even involved in the backup!
Example: I backup the whole drive c:/ with repair partition.
The detected files "touched" are on drive d: that is not backed up with True Image.
You can see that effect when you do a backup to a Samba destination but cancel the whole backup before it starts
or when using a local drive as backup destination when you run the backup.
The change of date and time is somehow erratic.
My example: from about 20,000 files only 4 change to an older date+time, 120 to a newer (but not "today"!)
and the rest simply does not change the time stamp at all.
I have that issue on two different machines (at home and office) that hold the same files and I synchronise them by a USB-stick and the directory synch option of total commander.
...the both machines simply hold copies of the files, they are not connected online in any way.
I have an archive of older versions of True Image and found that problems came up with 2019.
The 2018 build 12510 is OK. From 2019 I have builds 13660 and 14110 that both show the issue.
I'm sorry but I think I will keep on using 2018_12510 until this is fixed.
And no: I consider it not as a feature to "touch" files unnecessarily! ;-)
Thank you!
I did as advised and opened a ticket on that issue.
I could reliably reproduce the effect. Manually checked a few of the files and the timestamp changed to exactly the same wrong state (not a second different = no "offset" to system time) when using both versions of ATI 2019 I have available.
Uwe, please let us know the outcome of your ticket as this will be of interest to other users too.
I uploaded all required data and they are investigating it.
From my own explorations I detected that only ZIP-files are affected.
Keep you informed...
Thanks Uwe.
It's not running to my satisfaction.
They analysed the log files but don't see that file dates are changed - of course not, because the files are not even included in the backup, they are on drives that are connected to the system during backup.
May I show two screen shots (sorry for German Windows)?
The file's properties before the backup.
The file's properties after the backup:
Note: the different locations (D:\BitTorrent vs. G:\backupD\BitTorrent) result in the reason that I do not know beforehand, which files will be changed after the Backup. On drive G: is simply a mirror of the original file from D: with the properties from before the backup.
You might notice the change in timestamps for creation and access.
The backup obviously ran on 23.Oct.2018 around 13:35.
My idea is, that the underlying Linux system might open and inspect the ZIP files - though they are not even included in the backup - and so it changes timestamps.
Has anyone else noticed such changes?
I would blame it on one (somehow screwed) system but I notice the behaviour on two different systems.
I will stick with 2018 build 12510 that does the job to my satisfaction.
2019 with those side effects is not usable for me.
Uwe, is this issue only occurring when using the bootable Acronis Rescue Media, or does it happen also when using the main Windows ATI application?
Over the years the installed version appeared harder and harder to use for something so simple, as a backup/restore. ;-)
So since ATI 2016 I did only use the bootable medium from the download.
...but I will give it a try, though I really don't like the installed application.
So it might show if the backup mechanism or the boot-system causes the problem.
...BTW is it possible to get a simple terminal when running the boot media?
So I could inspect the files at different points when "clicking together" the backup.
I noticed time stamp changes even when running through the whole backup but just aborting the final "Proceed", just "preparing" for backup but do not do it in the end.
Uwe, I can see what looks to be the issue you are describing in this topic when I ran a backup from my MVP Custom WinPE Rescue Media of my C: OS drive but where checking 3 zip files on my E: drive shows that they were 'Accessed' during this process.
The date/time stamps for these 3 zip files were not changed, i.e. the date/time when the files were Created and when they were Modified remain the same. It is only the date they were Accessed that has been updated during the offline Acronis backup processing!
To my mind, the date Accessed should not influence any file synchronisation utilities such as RoboCopy etc, because files can be accessed by other utilities such as AntiVirus software doing checks for archive contents looking for malware but without making any other change.
The one strange thing about the date/time Accessed information is that it looks to be using a different time zone to my default GMT (London) time, thus shows as being in the future when checked from Windows.
My current date/time is 05 November 2018 19:22 (after restarting into Windows) but the Accessed date/time shows as 06 November 2018 01:38:52 for the zip file.
BTW is it possible to get a simple terminal when running the boot media?
So I could inspect the files at different points when "clicking together" the backup.
Yes, if you create the MVP Custom ATIPE version of the Acronis Rescue Media - this comes with a number of extra features above the normal Acronis media options, including a File Explorer, Command Prompt, screen capture, web browser etc. Link in my signature.
Short result: the installed application does not change time stamps of uninvolved ZIP-files.
Thank you so much for also testing the issue! :-)
I will try to build such a MVP boot medium for further testing.
Hi, I found this thread because I had exactly the same issue.
Booting a Linux Trueimage 2019 system modifies all ZIP files on every attached media.
The main disk from which I create the image, and also on the USB HD drive receiving the image file!
The problem does NOT happen when booting a WinRE Trueimage 2019 system.
Conslusion: there is a problem!
Solution for me at the moment: do not use Linux boot Trueimage, use WinRE boot media
For the issue with Linux TI system and weired modified dates I found a solution as well, any one of these make the date stamps back to original, but only the file system check does it automatically:
- open the zip file once (in Windows)
- copy the zip file once (in Windows)
- select one or several zip files and check their properties (in Windows, ALT-Return)
- run a file system check on the affected disk (most efficient because it is automatic)
I wonder if the Linux boot media version can be fixed?
Thanks
Peter
Peter, ATI 2019 went out of support around September 2019 so there will be no fixes for any of the features of that version.
Acronis is moving away from using Linux based rescue media in favour of using Windows PE media, where this issue does not exist. This move started with ATI 2018 where the WinPE media is created via the Simple option using the Windows Recovery Environment data so as to not need users to install a Windows ADK for the PE components.