TeraByte Unlimited

I accidently deleted a file on my d: drive, and I wanted it back so I opened TBIMOUNT on the "2013-09-28-0030-D_DRIVE-.TBI"
file and received this error: "Insert media 2 containing file I:\2013-09-28-0030-D_DRIVE-.1" then after unsuccessful (OK) attempts: "Unable to open file" and "Error 6 while reading meta data from TBI file."

Here is a partial directory on my I:\ drive:
10/01/2013 02:37 AM 4,294,966,784 2013-09-28-0030-D_DRIVE-.1
10/01/2013 02:43 AM 4,294,966,784 2013-09-28-0030-D_DRIVE-.2
10/01/2013 02:46 AM 2,636,027,392 2013-09-28-0030-D_DRIVE-.3
10/01/2013 02:46 AM 4,294,966,784 2013-09-28-0030-D_DRIVE-.TBI

Here is the TBI Mount command that was used:
I:\>d:\apps\tbiview\tbimount mount * "2013-09-28-0030-D_DRIVE-.TBI" /sch i:\

I then ran both IFD and IFW to validate the 2013-09-28-0030-D_DRIVE-.TBI file, and both validations passed successfully.

I would like to get the missing file back, but do not want to try a restore for fear that some error might occur in the middle of the process, and I would loose everything. I'm also concerned that maybe a successful backup and validation does not mean that everything is well.

I should also let you know that the (base) "2013-09-28-0030-D_DRIVE-.TBI" is a combination of a base and 4 incremental files that were created on Saturdays in month 09. On the first of the month I have a process that uses the IFD image /combine process to create a new monthly base. The new monthly base was created on the 1st of October and its base name is the name of the last (Friday) incremental. That is why the file dates and names are a little confusing. The log indicates that the /combine and all other incremental processes completed successfully without error.

Any ideas why TBIVIEW and TBIMOUNT show this error, while Image.exe and imagew.exe both continue to validate without problems? Is it safe to do a restore over my existing data? Any suggestions on how to debug the problem further?

( I should let you know that a TBIMOUNT on the Friday 9/28 incremental was successful so I got my file back. This incremental file was created before the new base /combine file was created. Because this is my first test of the new /COMBINE functions, I'm a little worried about the ability to restore in the future. Because all October incrementals were based on the new 9/28 combined base, none of the October incrementals will mount/view either as it is asking for that same .1 fie to be inserted. Again, I'm worried that successful backups, combines and validates will not mount, view, and possibly restore. and if true then I loose confidence in your products. ) How can I help find the problem?

Later this day I did some additional testing. I successfully restored the file that TBIMount and TBIView could not handle. So the problem is with those products. Please feel free to move this item to a more appropriate forum, and my confidence in IDF/IFW is restored as well.

Both TBIView and TBIMount gave the same message?

What versions?

How was the file size determined (4G in the UI, or max size because fat32,
or manually entered the full byte amount) ?



"tas3086" wrote in message news:[email protected]...

I accidently deleted a file on my d: drive, and I wanted it back so I opened
TBIMOUNT on the "2013-09-28-0030-D_DRIVE-.TBI"
file and received this error: "Insert media 2 containing file
I:\2013-09-28-0030-D_DRIVE-.1" then after unsuccessful (OK) attempts:
"Unable to open file" and "Error 6 while reading meta data from TBI file."

Here is a partial directory on my I:\ drive:
10/01/2013 02:37 AM 4,294,966,784 2013-09-28-0030-D_DRIVE-.1
10/01/2013 02:43 AM 4,294,966,784 2013-09-28-0030-D_DRIVE-.2
10/01/2013 02:46 AM 2,636,027,392 2013-09-28-0030-D_DRIVE-.3
10/01/2013 02:46 AM 4,294,966,784 2013-09-28-0030-D_DRIVE-.TBI

Here is the TBI Mount command that was used:
I:\>d:\apps\tbiview\tbimount mount * "2013-09-28-0030-D_DRIVE-.TBI" /sch
i:\

I then ran both IFD and IFW to validate the 2013-09-28-0030-D_DRIVE-.TBI
file, and both validations passed successfully.

I would like to get the missing file back, but do not want to try a restore
for fear that some error might occur in the middle of the process, and I
would loose everything. I'm also concerned that maybe a successful backup
and validation does not mean that everything is well.

I should also let you know that the (base) "2013-09-28-0030-D_DRIVE-.TBI"
is a combination of a base and 4 incremental files that were created on
Saturdays in month 09. On the first of the month I have a process that
uses the IFD image /combine process to create a new monthly base. The new
monthly base was created on the 1st of October and its base name is the name
of the last (Friday) incremental. That is why the file dates and names are
a little confusing. The log indicates that the /combine and all other
incremental processes completed successfully without error.

Any ideas why TBIVIEW and TBIMOUNT show this error, while Image.exe and
imagew.exe both continue to validate without problems? Is it safe to do a
restore over my existing data? Any suggestions on how to debug the problem
further?

( I should let you know that a TBIMOUNT on the Friday 9/28 incremental was
successful so I got my file back. This incremental file was created before
the new base /combine file was created. Because this is my first test of
the new /COMBINE functions, I'm a little worried about the ability to
restore in the future. Because all October incrementals were based on the
new 9/28 combined base, none of the October incrementals will mount/view
either as it is asking for that same .1 fie to be inserted. Again, I'm
worried that successful backups, combines and validates will not mount,
view, and possibly restore. and if true then I loose confidence in your
products. ) How can I help find the problem?

Later this day I did some additional testing. I successfully restored the
file that TBIMount and TBIView could not handle. So the problem is with
those products. Please feel free to move this item to a more appropriate
forum, and my confidence in IDF/IFW is restored as well.

The problem is resolved, it was my error.

The .TBI .1 .2 .3 ... files were created under a BootitBM/TBOS/(DOS) environment. I ran TBIMount and TBIView under a Windows environment on a NTFS Drive. While I had ownership and permission to access the .TBI files, I did not have ownership of the .1 file that was causing the error.

I have adjusted my scripts to correct this problem and give me ownership. Sorry for your time that I wasted. Hopefully this finding may help someone in the future. My confidence in your products is completely and utterly restored to its maximum.
Terry