Filename/date wrong in Home 2010
Hello all
I'm having an odd issue with ATI automatically appending the wrong date to my backups. Can't find anything in the forum on this, so I don't know whether it's a bug or something I'm doing. . . comments appreciated!
I set the backup location for my tasks to end in \taskname-@date@, and the resulting .tib files are fine, with the current date. It's the "inner" filename I'm having trouble with -- sorry, I don't know the proper terminology for this; it's the job/taskname (?) that shows in bold in the Acronis Recovery window, and in Explorer one level below the expanded .tib with an icon that looks like a container of some kind.
I'm attaching a screenshot to show what I mean: the expanded pairs of TEST- and Backup- entries have the same date appended to the name, though they were run on subsequent days. Yet the .tib files, as shown in the path, are named and dated correctly.
After testing over a few days, as far as I can make out what's happening is that the date being added is the date the job was previously run. For example, yesterday I backed up the two utility partitions on my Dell (not something I do regularly!), just to test this. The .tib had the correct date but the job showed up in Recovery as "SystemD&Utility_28/11/2009"!
If I delete a wrongly-dated backup, and run it again, the second time it's right -- presumably because the "last run" date is now the current one.
The tasks are all full backups and just to be clear, none of their names include a date or date tag. It's being added by the program and there doesn't seem any way to stop it. It's not a huge problem: I've been renaming the files, but I'm really curious as to why this is happening. Could it be because the jobs are all run manually, not scheduled?
More thoughts: to avoid the full backups being overwritten, I normally have Acronis create them in a temp folder and then use a post-processing command to move them. But I ran the TEST- task without post-processing, leaving it in the temp folder, and the date was still wrong. I've also tried playing with the task names, trying e.g. :
Backup
Backup- (my usual format)
Backup-@date@
but it made no difference.
I'm surprised nobody else has mentioned this, so perhaps I'm doing something wrong? I'd be very grateful for any pointers.
My only observation is with the time when a backup is done manually via the boot CD. It is off by 8 hours - don't remember in which direction.
Backups done from within Windows are correct though since it takes the date and time from the computer's date and time.
DwnNDrty, thanks very much for replying. I did wonder if it was an issue with time zones (I am in the UK), but it definitely more than that. For example, yesterday (the 8th) I ran a task that hadn't been run for three days. Result: correct date in the .tib, displayed backup name with previous run date added (05_02_2010). I've also answered my own question as to whether this is because of the tasks being unscheduled; the answer is No again, tried scheduling and exactly the same result.
My gripes are:
1) Why does TI insist on adding a date to the taskname?
2) If it has to, why isn't it the file creation date, rather than the date the task was last run? I can't think of any reason why anyone would want that. And it means that, after the first run of a task, the date is always wrong.
3) Why can't we have the .tib name (which includes the correct date) displayed under Name in the Acronis Recovery window, instead of this job/taskname? I'm using a post-processing batch file to rename .tibs along the lines GroverH explains here: forum.acronis.com/forum/6298#comment-15207 . The screenshot he attached to that post seems to show that previous versions of TI did this. There doesn't seem to be any way of altering what's shown in Recovery, unless someone knows a hack for the xml task files?
I want to like TI Home 2010, I really do, but I'm really starting to get fed up now. Not only do I have to move my full backups to stop the program overwriting them, I now have to manually rename them all as well in order for what's shown in the Recovery window to make any kind of sense.