Toshiba Glist issue

[terminator2]

I have got a Toshiba MQ04ABF100 laptop hard disk . It is getting detected and I have copied MFT's as well.
But while imaging it stays busy or becomes non ready .I think it is because of hugh defects in Glist.
I have copied glist without any error.
How can I efficiently deal with Glist and make imaging smooth
I have attached SABACKUp with glist as well.
download -
https://drive.google.com/file/d/1-kXmo0 ... sp=sharing

Attachments

[fzabkar]

"Access denied"

[terminator2]

"Access denied"

Thanks fzabkar
Sorry I forgot to change sharing .
Here is download link - https://drive.google.com/file/d/1-kXmo0 ... sp=sharing

[fzabkar]

The "SP" command in terminal toggles ARRE.

[fzabkar]

Your G-list (0x6000 bytes) is smaller than the storage required for the number of records in the header (0x4849C bytes).

0x6061 records x 12 bytes per record + 0x10 byte header = 0x4849C bytes

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B

00000000  53 50 61 60 CD C6 01 00 00 00 00 00  SP..........
                ^^^^^
                number of records = 0x6061

0000000C  00 00 00 00 8A 02 00 00 01 00 60 06
                      ^^^^^^^^^^^^^^^^^^^^^^^  <-- first record
00000018  10 00 00 80 BF 02 00 00 01 00 88 02
          ^^^^^^^^^^^
........
00005FE8  10 00 00 80 5F 3D 02 00 01 0E 70 09
00005FF4  08 00 00 80 61 3D 02 00 01 0E 00 00  <-- last record overflows the G-list
                      ^^^^^^^^^^^^^^^^^^^^^^^

Are you able to dump the SA tracks?

[terminator2]

Your G-list (0x6000 bytes) is smaller than the storage required for the number of records in the header (0x4849C bytes).

0x6061 records x 12 bytes per record + 0x10 byte header = 0x4849C bytes

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B

00000000  53 50 61 60 CD C6 01 00 00 00 00 00  SP..........
                ^^^^^
                number of records = 0x6061

0000000C  00 00 00 00 8A 02 00 00 01 00 60 06
                      ^^^^^^^^^^^^^^^^^^^^^^^  <-- first record
00000018  10 00 00 80 BF 02 00 00 01 00 88 02
          ^^^^^^^^^^^
........
00005FE8  10 00 00 80 5F 3D 02 00 01 0E 70 09
00005FF4  08 00 00 80 61 3D 02 00 01 0E 00 00  <-- last record overflows the G-list
                      ^^^^^^^^^^^^^^^^^^^^^^^

Are you able to dump the SA tracks?

I will try to get SA tracks and revert. Thank You so much fzabkar

[terminator2]

Your G-list (0x6000 bytes) is smaller than the storage required for the number of records in the header (0x4849C bytes).

0x6061 records x 12 bytes per record + 0x10 byte header = 0x4849C bytes

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B

00000000  53 50 61 60 CD C6 01 00 00 00 00 00  SP..........
                ^^^^^
                number of records = 0x6061

0000000C  00 00 00 00 8A 02 00 00 01 00 60 06
                      ^^^^^^^^^^^^^^^^^^^^^^^  <-- first record
00000018  10 00 00 80 BF 02 00 00 01 00 88 02
          ^^^^^^^^^^^
........
00005FE8  10 00 00 80 5F 3D 02 00 01 0E 70 09
00005FF4  08 00 00 80 61 3D 02 00 01 0E 00 00  <-- last record overflows the G-list
                      ^^^^^^^^^^^^^^^^^^^^^^^

Are you able to dump the SA tracks?

No I can't read any SA tracks .Attached is snap of the error. I am getting error in P list as well.

Attachments

[fzabkar]

It appears that this model still isn't supported by your tool. I expect that the real size of the G-list is greater than 0x6000 bytes, otherwise one would expect problems when the module overflows.

In short, I think my observation is a red herring, but you won't know for sure until your tool is updated.

[terminator2]

It appears that this model still isn't supported by your tool. I expect that the real size of the G-list is greater than 0x6000 bytes, otherwise one would expect problems when the module overflows.

In short, I think my observation is a red herring, but you won't know for sure until your tool is updated.

Oh
But I am using updated pc3000 (v 7.1.10) . I can give remote access to pc as well

[Doomer]

pc3k does not support this model

[terminator2]

pc3k does not support this model

fzabkar & Doomer both of you are great thorough professionals with other members .Appreciate your technical skills.

fzabkar has identified actual technical issue even without having physical access to hard disk. Its wonderful analytical skill.
I am wondering how you peoples deal with such cases ? I think pc3000 is the best tool but if it does not support then how to solve this case.

[Doomer]

AFAIK fzabkar is a great analyst but he is not involved in data recovery.
There are no commercial tools that support this model yet, I have my own tools.

From the description you gave your drive might have unstable heads (one of them) or developing media damage, could be something else. But it is unlikely that a full G-List would result in such behavior.

PS: the "SP" file you are seeing is not even a real module, it's a virtual table in drive's memory, on the contrary to "GL" module on older drives.

[terminator2]

AFAIK fzabkar is a great analyst but he is not involved in data recovery.
There are no commercial tools that support this model yet, I have my own tools.

From the description you gave your drive might have unstable heads (one of them) or developing media damage, could be something else. But it is unlikely that a full G-List would result in such behavior.

PS: the "SP" file you are seeing is not even a real module, it's a virtual table in drive's memory, on the contrary to "GL" module on older drives.

I am totally flattened ,great you have developed your own tools.
It seems I have little hope now. Even if heads transplanted ,this SA / FW issue will still persist.