Testdisk reporting excessive disk size

How to use TestDisk to recover lost partition
Forum rules
When asking for technical support:
- Search for posts on the same topic before posting a new question.
- Give clear, specific information in the title of your post.
- Include as many details as you can, MOST POSTS WILL GET ONLY ONE OR TWO ANSWERS.
- Post a follow up with a "Thank you" or "This worked!"
- When you learn something, use that knowledge to HELP ANOTHER USER LATER.
Before posting, please read https://www.cgsecurity.org/testdisk.pdf
Locked
Message
Author
gmilliorn
Posts: 3
Joined: 12 Dec 2023, 17:14

Testdisk reporting excessive disk size

#1 Post by gmilliorn »

My disk became RAW: after my graphics card committed suicide. I've been running TestDisk and
so far finding nothing. In diskmgr i see:
Image
which is odd because both disk 0 and 1 are 2TB disks.

Running Testdisk most recently shows this (I've run multiple times, takes about 8 hrs or so):

Code: Select all


Mon Dec 11 16:03:55 2023
Command line: TestDisk

TestDisk 7.2-WIP, Data Recovery Utility, February 2023
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org
OS: Windows 8 (9200)
Compiler: GCC 11.2, Cygwin 3001.4
ext2fs lib: 1.45.3, ntfs lib: 10:0:0, reiserfs lib: none, ewf lib: 20140608, curses lib: ncurses 6.1
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive0)=2000398934016
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive1)=2000398934016
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive2)=500107862016
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\C:)=499460190208
filewin32_getfilesize(\\.\D:) GetFileSize err Incorrect function.

filewin32_setfilepointer(\\.\D:) SetFilePointer err Incorrect function.

Warning: can't get size for \\.\D:
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\F:)=4000773570560
Hard disk list
Disk \\.\PhysicalDrive0 - 2000 GB / 1863 GiB - CHS 243201 255 63, sector size=512 - ST2000VN004-2E4164, S/N:Z5293ZTD, FW:SC60
Disk \\.\PhysicalDrive1 - 2000 GB / 1863 GiB - CHS 243201 255 63, sector size=512 - ST2000VN004-2E4164, S/N:Z529403A, FW:SC60
Disk \\.\PhysicalDrive2 - 500 GB / 465 GiB - CHS 60801 255 63, sector size=512 - Samsung SSD 970 EVO 500GB, S/N:0025_385A_0144_5D9D., FW:2B2QEXE7

Partition table type (auto): EFI GPT
Disk \\.\PhysicalDrive0 - 2000 GB / 1863 GiB - ST2000VN004-2E4164
Partition table type: Intel

Analyse Disk \\.\PhysicalDrive0 - 2000 GB / 1863 GiB - CHS 243201 255 63
Geometry from i386 MBR: head=255 sector=63
check_part_i386 1 type EE: no test
Current partition structure:
 1 P EFI GPT                  0   0  2 267349  89  4 4294967295

Bad sector count.
No partition is bootable

search_part()
Disk \\.\PhysicalDrive0 - 2000 GB / 1863 GiB - CHS 243201 255 63

recover_EXT2: s_block_group_nr=0/18, s_mnt_count=2/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 622544
recover_EXT2: part_size 4980352
Filesystem created: Fri Dec 20 17:08:32 2019
Last mount time:    Sat Dec 28 09:34:52 2019
     Linux                    0  32 33   310  35 45    4980352 [1.42.6-23824]
     ext4 blocksize=4096 Large_file Sparse_SB, 2549 MB / 2431 MiB
BAD_RS LBA=2954758104 3206608
check_part_i386 failed for partition type 0E
     FAT16 LBA            183925  47 19 295319 134  3 1789550076
This partition ends after the disk limits. (start=2954758104, size=1789550076, end=4744308179, disk end=3907029168)
BAD_RS LBA=4018951817 16099123
check_FAT: can't read FAT boot sector
check_part_i386 failed for partition type 0C
     FAT32 LBA            250168  45 63 308937 246 14  944136600
This partition ends after the disk limits. (start=4018951817, size=944136600, end=4963088416, disk end=3907029168)
BAD_RS LBA=4210342367 361558
check_FAT: can't read FAT boot sector
check_part_i386 failed for partition type 01
     FAT12                262081 176 15 520159 142 60 4146020974
This partition ends after the disk limits. (start=4210342367, size=4146020974, end=8356363340, disk end=3907029168)
Disk \\.\PhysicalDrive0 - 2000 GB / 1863 GiB - CHS 243201 255 63
Check the hard disk size: HD jumper settings, BIOS detection...
The hard disk (2000 GB / 1863 GiB) seems too small! (< 4278 GB / 3984 GiB)
The following partitions can't be recovered:
     FAT16 LBA            183925  47 19 295319 134  3 1789550076
     FAT32 LBA            250168  45 63 308937 246 14  944136600
     FAT12                262081 176 15 520159 142 60 4146020974

Results
   * Linux                    0  32 33   310  41 51    4980736 [1.42.6-23824]
     ext4 blocksize=4096 Large_file Sparse_SB, 2550 MB / 2432 MiB


dir_partition inode=2
   * Linux                    0  32 33   310  41 51    4980736 [1.42.6-23824]
     ext4 blocksize=4096 Large_file Sparse_SB, 2550 MB / 2432 MiB
ext2fs_dir_iterate failed with error 2133571363.
Directory /
Can't open backup.log file: No such file or directory
interface_load


dir_partition inode=2
   * Linux                    0  32 33   310  41 51    4980736 [1.42.6-23824]
     ext4 blocksize=4096 Large_file Sparse_SB, 2550 MB / 2432 MiB
ext2fs_dir_iterate failed with error 2133571363.
Directory /
Change partition type:
   * Linux                    0  32 33   310  41 51    4980736 [1.42.6-23824]
     ext4 blocksize=4096 Large_file Sparse_SB, 2550 MB / 2432 MiB
Change partition type:
   * ext4                     0  32 33   310  41 51    4980736 [1.42.6-23824]
     ext4 blocksize=4096 Large_file Sparse_SB, 2550 MB / 2432 MiB


dir_partition inode=2
   * Linux                    0  32 33   310  41 51    4980736 [1.42.6-23824]
     ext4 blocksize=4096 Large_file Sparse_SB, 2550 MB / 2432 MiB
ext2fs_dir_iterate failed with error 2133571363.
Directory /

interface_write()
 1 * Linux                    0  32 33   310  41 51    4980736 [1.42.6-23824]

search_part()
Disk \\.\PhysicalDrive0 - 2000 GB / 1863 GiB - CHS 243201 255 63

recover_EXT2: s_block_group_nr=0/18, s_mnt_count=2/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 622544
recover_EXT2: part_size 4980352
Filesystem created: Fri Dec 20 17:08:32 2019
Last mount time:    Sat Dec 28 09:34:52 2019
     Linux                    0  32 33   310  35 45    4980352 [1.42.6-23824]
     ext4 blocksize=4096 Large_file Sparse_SB, 2549 MB / 2431 MiB
NTFS at 1/5/5
filesystem size           7814010880
sectors_per_cluster       8
mft_lcn                   786432
mftmirr_lcn               2
clusters_per_mft_record   -10
clusters_per_index_record 1
     HPFS - NTFS              1   5  5 486400 178 50 7814010880
     NTFS, blocksize=4096, 4000 GB / 3726 GiB
This partition ends after the disk limits. (start=16384, size=7814010880, end=7814027263, disk end=3907029168)
BAD_RS LBA=2954758104 3206608
check_part_i386 failed for partition type 0E
     FAT16 LBA            183925  47 19 295319 134  3 1789550076
This partition ends after the disk limits. (start=2954758104, size=1789550076, end=4744308179, disk end=3907029168)
BAD_RS LBA=4018951817 16099123
check_FAT: can't read FAT boot sector
check_part_i386 failed for partition type 0C
     FAT32 LBA            250168  45 63 308937 246 14  944136600
This partition ends after the disk limits. (start=4018951817, size=944136600, end=4963088416, disk end=3907029168)
BAD_RS LBA=4210342367 361558
check_FAT: can't read FAT boot sector
check_part_i386 failed for partition type 01
     FAT12                262081 176 15 520159 142 60 4146020974
This partition ends after the disk limits. (start=4210342367, size=4146020974, end=8356363340, disk end=3907029168)
Disk \\.\PhysicalDrive0 - 2000 GB / 1863 GiB - CHS 243201 255 63
Check the hard disk size: HD jumper settings, BIOS detection...
The hard disk (2000 GB / 1863 GiB) seems too small! (< 4278 GB / 3984 GiB)
The following partitions can't be recovered:
     HPFS - NTFS              1   5  5 486400 178 50 7814010880
     NTFS, blocksize=4096, 4000 GB / 3726 GiB
     FAT16 LBA            183925  47 19 295319 134  3 1789550076
     FAT32 LBA            250168  45 63 308937 246 14  944136600
     FAT12                262081 176 15 520159 142 60 4146020974

Results
   * Linux                    0  32 33   310  41 51    4980736 [1.42.6-23824]
     ext4 blocksize=4096 Large_file Sparse_SB, 2550 MB / 2432 MiB
Failed to startup volume: Invalid argument.

Disk 0 is the failing disk, which used to be "F:". Disk 1 is only there for pending backup/copy purposes. Both
are 2TB disks, but Windows DiskMgr shows the failed disk as 3.726GB somehow.

Running testdisk, scan and deepscan seem to always insist it is Linux EXT4, but this has only been used for
Windows and is FAT32 as best I recall. Forcing the FS type to NTFS or FAT32 shows no files. PhotoRec
does find lots of files, though, so data is still there.

When I look at the logs, it seems like TestDisk is also annoyed by the incorrect size.
https://milliorn.org/testdisk1.log

Is that related? Is this "incorrect size" related to why I can't find files/a filesystem?

Here's a snippet of PhotoRec.log if interesting:

Code: Select all

en
translator not installed


Tue Dec 12 08:59:25 2023
PhotoRec 7.2-WIP, Data Recovery Utility, February 2023
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org
OS: Windows 8 (9200)
Compiler: GCC 11.2, MinGW 3.11
ext2fs lib: none, ntfs lib: 10:0:0, ewf lib: 20140608, libjpeg: libjpeg-turbo-2.1.1
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive0)=2000398934016
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive1)=2000398934016
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\PhysicalDrive2)=500107862016
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\C:)=499460190208
filewin32_getfilesize(\\.\D:) GetFileSize err Incorrect function.


filewin32_setfilepointer(\\.\D:) SetFilePointer err Incorrect function.


Warning: can't get size for \\.\D:
disk_get_size_win32 IOCTL_DISK_GET_LENGTH_INFO(\\.\F:)=4000773570560
Partition table type (auto): EFI GPT
Disk \\.\PhysicalDrive0 - 2000 GB / 1863 GiB (RO) - ST2000VN004-2E4164
check_part_gpt failed for partition
 1 P MS Reserved              0   0 35     2  10  8      32734 [Microsoft reserved partition]
check_part_gpt failed for partition
 2 P MS Data                  2  10  9 486401 183 54 7814010880 [Basic data partition]
       0 0000 0000 00 00 00 00 00 00 00 00
     Unknown                  0   0  1 243201  80 63 3907029168 [Whole disk]
 1 P MS Reserved              0   0 35     2  10  8      32734 [Microsoft reserved partition]
 2 P MS Data                  2  10  9 486401 183 54 7814010880 [Basic data partition]
       0 0000 0000 00 00 00 00 00 00 00 00
       0 0000 0000 00 00 00 00 00 00 00 00
     Unknown                  0   0  1 243201  80 63 3907029168 [Whole disk]
742 first-level signatures enabled
blocksize=1024, offset=0
C:/recover1/recup_dir.1/f0002050.ext	 2050-2051
C:/recover1/recup_dir.1/f0016400.mft	 16400-16401
C:/recover1/recup_dir.1/f0016402.mft	 16402-16403
C:/recover1/recup_dir.1/f0016404.mft	 16404-16405
C:/recover1/recup_dir.1/f0016406.mft	 16406-16407
C:/recover1/recup_dir.1/f0016544.xml	 16544-16549
C:/recover1/recup_dir.1/f0031096.xml	 31096-31103
C:/recover1/recup_dir.1/f0031104.jpg	 31104-31203
where it seems to find MSoft partitions

Thanks for any suggestions!
Last edited by gmilliorn on 15 Dec 2023, 21:51, edited 1 time in total.
recuperation
Posts: 3026
Joined: 04 Jan 2019, 09:48
Location: Hannover, Deutschland (Germany, Allemagne)

Re: TestDisk

#2 Post by recuperation »

Have you removed your disk from an external housing when trying to rescue your data?
Did you partition the disk?
If so, did you choose GPT or MBR?
The log entries rather suggest that you used the GPT scheme.

It seems very strange to me that the Photorec logfile shows different partition information than Testdisk does.

It appears to me that you are doing something wrong but I don't know what that is, unfortunately.
gmilliorn
Posts: 3
Joined: 12 Dec 2023, 17:14

Re: TestDisk

#3 Post by gmilliorn »

Thanks for responding.

The disk is in a desktop PC attached to a SATA port.

I don't have a record of when I first attached it, however it was not intended to be
bootable so I believe I just partitioned it to whatever Windows offered to use the
entire disk. It probably was GPT, as you say.

Looking at TestDisk's filesystem report, it shows:

Code: Select all

      Partition                  Start        End    Size in sectors
> 1 P MS Reserved                   34      32767      32734 [Microsoft reserved partition]
  2 P MS Data                    32768 7814043647 7814010880 [Basic data partition]                                                                                                                                                              
 
TestDisk correctly identified the disk info (2000 GB / 1863 GiB - CHS 243201 255 63, sector size=512) which all checks out,
so I guess not only the GPT but something important to the filesystem got wiped out as well? I am not seeing an option about
that though.
recuperation
Posts: 3026
Joined: 04 Jan 2019, 09:48
Location: Hannover, Deutschland (Germany, Allemagne)

Re: TestDisk

#4 Post by recuperation »

Your statement
> The disk is in a desktop PC attached to a SATA port."
does not answer my question
> Have you removed your disk from an external housing when trying to rescue your data?
unfortunately.

Try to follow the standard procedure outlined in

https://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

and don't forget to check each partition for recoverable content using the p-key ("list files").

Using "Testdisk" as a title for a posting leaves others successfully in the dark which is sad.
gmilliorn
Posts: 3
Joined: 12 Dec 2023, 17:14

Re: Testdisk reporting excessive disk size

#5 Post by gmilliorn »

> Have you removed your disk from an external housing when trying to rescue your data?

No, it is and still was on a motherboard SATA port.

As of 36 hours of quick search + deeper search, the status is:

Code: Select all

TestDisk 7.2-WIP, Data Recovery Utility, February 2023
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org

Disk \\.\PhysicalDrive1 - 2000 GB / 1863 GiB - CHS 243201 255 63
Analyse cylinder 193485/243200: 79%


  Mac HFS                373519215  407073904   33554690
  Mac HFS                339964529  373519218   33554690
  Mac HFS                396905541 3263204760 2866299220 ["M-w DM-g M-;Q~] i^X^C^B^DJUm^D]
  Mac HFS                431967556  432065989      98434
  Mac HFS                431869126  431967559      98434
  Linux filesys. data    647516131  655383471    7867340 [wH^?M-$^HT M-&~CM-H;Xv]
  Linux filesys. data    647516132  655383472    7867340 [wH^?M-$^HT M-&~CM-H;Xv]
  Mac HFS                798529199  856200919   57671721
  Mac HFS                740857482  798529202   57671721
  Linux filesys. data    836536283  844403623    7867340 [wH^?M-$^HT M-&~CM-H;Xv]
  Linux filesys. data    836536284  844403624    7867340 [wH^?M-$^HT M-&~CM-H;Xv]
  Mac HFS                850602815 4947984766 4097381952 [BM-?M-R~A^^~? M-%9^B]
  Mac HFS                874768826 1513875899  639107074
  Mac HFS                235661756  874768829  639107074                                                                                                                                                                                       check_FAT: Bad jump in FAT partition                                                                                     check_FAT: Bad jump in FAT partition                              72 [^GM-<Y~Q
M-$,^B^BFM-1^WM->^\^[^^-~\^W~]9M- M-#M-)M-/~Q Ka                                                                       check_FAT: Bad jump in FAT partition
check_FAT: Bad jump in F3062387899 22874242966639801 22874239904251904                                                                                                  
The first 6 were found on the previous run, zero of them contained any files using 'p'.
Since this disk was never Mac HFS or Linux, not really surprising. I am letting it run to
completion anyway, it will probably take 4-5 more hours. Perhaps it will find a windows GPT somewhere.
Locked