Mounting image error / tib image id data
Hi,
I think Steve Smith has this info, but I know he prefers a new topic vs. private mail. The following really (in part or fully) can apply to TI 2016/2017/2018. As a background I have a number of PCs with TI installed. While I do occasionally use the windows main program (usually to mount a FULL DRIVE image backup, via the Windows Explorer context menu) to retrieve a single file contained therein. I always create (using the MVP program) a WIN PE boot USB drive, by which I actually create all of my FULL DRIVE IMAGE Backups, and to Restore such a FULL DRV TIB to a FRESH HDD in case of (e.g.) a program or Windows update gone rogue. Also, I must say the using the WINPE "rescue" USB boot method is (for ME) VERY stable and more flexible compared to the Windows Full Program...plus, have 10+ systems here, I simple backup/restore images from several Large USB drives. Again, I ONLY create FULL DRIVE IMAGE BACKUPS...never incremental, nor File/Folder backups-and I verify every backup.
So, today, I was looking for an old file, and so wanted to use the ATI Windows Program to mount an Image....and it failed with the error "Cannot assign a drive letter to a partition from a backup archive". Browsing the support section of Acronis, I do find prior posts, and patches (you mentioned...some time ago.). Let me say that SOME TIB (FULL) images WILL mount and assign drive letters. The case in point is a PC with ATI 2016-6595 installed. As far as I can determine some TIB's DO NOT have this issue, others do. All verify OK.
At the moment I am considering that (?) this might be an issue of a situation where I have an image created with ATI 2017 or 2018 and trying to mount with 2016-6595...But I do not think so. Obviously I am aware that the Main Windows based program, or rescue disk may not mount or process a backup file created with a NEWER ATI variant (e.g. FORWARD compatibility is NOT expected).
As a programmer I would expect that each TIB file would (perhaps in it header data) an identifier that would indicate the ATI VERSION (year/Release) that created the TIB file??? Surely? Do you have any info on this, utility tool that can retrieve it etc.
THANKS
BOB
Bob, please use the MVP Log Viewer tool (available via the Community Tools link below) and check what is shown in the TibMounter logs for when you have tried to Mount your backup .tib files.
This can be helpful in trying to understand what is happening here?
I see the following entries in my log for a mount of a small partition image:
05/08/2018 23:24:14 :407 [T] build: 2592; process: 10572; 'C:\Program Files (x86)\Acronis\TrueImageHome\TrueImageTools.exe'
05/08/2018 23:24:14 :407 [T] 2018.08.05 22:24:14 UTC
05/08/2018 23:24:14 :407 [T] 2018.08.05 23:24:14 LOCAL
05/08/2018 23:24:14 :407 [T] Control device '\\.\Global\TibMounterControl2592' handle=1564
05/08/2018 23:24:14 :408 [T] UserMan Init status 0x0
05/08/2018 23:24:14 :408 [T] DLL: 5.0.2592 Acronis TIB Mounter API
Copyright © Acronis International GmbH; 2002-2015.
Driver: 5.0.2592 Acronis TIB Mounter Driver
05/08/2018 23:24:14 :408 [T] vbInit status 0x0
05/08/2018 23:24:15 :138 [T] vbGetLogicalDrives result 0x7FC
05/08/2018 23:24:15 :139 [T] vbGetLogicalDrives result 0x7FC
05/08/2018 23:24:23 :282 [T] Mount TIB parameters:
paths:
H:\Test\ATIH2014USB_full_b1_s1_v1.tib
volumes:
2 U: RA
05/08/2018 23:24:23 :282 [T] BusInfo: 0 devices { }
05/08/2018 23:24:23 :283 [T] pathCount=1 [password] [encryptionKey]
05/08/2018 23:24:23 :330 [T] PrepareForMounting success
05/08/2018 23:24:23 :572 [T] remove handle=1844
05/08/2018 23:24:23 :572 [T] BusInfo: 1 devices { 0 }
05/08/2018 23:24:23 :572 [T] letter mask=0x100000
05/08/2018 23:24:26 :653 [T] Mount status 0x0 (3375 ms)
05/08/2018 23:24:26 :653 [T] vbMountTib status 0x0 (3375 ms)
05/08/2018 23:24:31 :050 [T] Passed ...
05/08/2018 23:24:31 :050 [T] Control device handle 1564 has been closed
05/08/2018 23:24:31 :050 [T] vbDone status 0x0
Start: 05/08/2018 23:24:14
Stop: 05/08/2018 23:24:31
Total Time: 00:00:17
In the above, it shows the full path of the image being mounted and then the drive letter assigned for this (U:). The image was of a small USB stick with ATI 2014 rescue media mounted on my ATI 2018 system.
Dear Steve,
Thanks for your prompt response. In the meantime I have begun to sort-out some of the original issues. Without repeating myself, I had mentioned (due to my needs across several PCs, running win7,w10x86, w10x64, plus the fact that I have several 4-6 GB external USB drives to which I backup to and restore from...and I rotate these external drives (and thus the backups) for more security so that if a single ext. USB HDD backup drive fails it won't cause panic as by rotating the storage media 3x week, at worst I'd lose 2 days of work. With this in mind, with the inception of ATI 2015 up, swapping around the external storage media causes all sorts of confusion in terms of ATI's internal backup "database" of what was backed up, when, where and seemingly the actual TIB file name vs the backup name displayed in the WIN full applicaton. OK, I think you get it.
For that reason, plus any particular ext HDD BU drive might have backups from 6 PCs, and the original source of these backups might have been ATI 2016/17/18. For me ATI was just trying to become "too smart".
For this reason, I have created WINPE "RESCUE" USB drives. These cannot ONLY be used to Recover an image TIB FULL backup, but can also be used to CREATE a new full Drive Image TIB backup. In this way, I enter my own descriptive names, in my own method on the EXT USB drives. Never had an issue. These backups also Validate using the rescue USB or from within the Main Windows App.
I actually only use (mainly) the full ATI Windows Installed Program to Create the Rescue Win PE w/wo UR, Validate TIBs and occasionally to MOUNT a backup (produced by the RESCUE USB Backup made TIB. What I have found is that, seemingly without any cause I can find, some TIBs may not always Mount (Rt Clk Win Context window)...see my first post in this chain.) Then again, 10 minutes later it may work..or not. This issue is NOT tied to situations of trying to (for example) mounting a ATI 2017 produced TIB with a full Windows ATI 2016.
In all cases where this unreliable behavior occurs, I can, Using Windows explorer, simply expand the TIB (all my TIBs are 100% FULL Backups) and I have access to all partitions, folders & files.
My educated guess at this point, is that the TIB internal file structure when produced via Rescue Media vs. the Full Windows App are somehow inconsistent?? I would not expect this behavior to be by design? Any comments or ideas?
Thanks
Bob
Bob, I have never encountered any issues that suggest there could be differences in the TIB internal file structure between being created via the Windows app or via using Rescue media.
There is one tip to clear the TibMounter Cache that you can try to see if it makes a difference:
Try deleting all the files in C:\Users\[your_username]\AppData\Local\VirtualStore\ProgramData\Acronis\TrueImageHome\Database
This location may or may not exist when you look for it but the tip came from one of the Acronis Senior people (Slava) a while back and I saw it being suggested by Ekaterina recently in another forum topic.
Bob, if you visit the MVP User Tools and Tutorials repository on Google Drive, there is a batch file there created by Bobbo back in 2016 for automating the clearing of the TibMounter cache and which handles the case where the location doesn't exist.