On Wed, 5/7/2025 4:27 AM, scbs29 wrote:
Can anyone please help ?
I have a 6TB USB HDD attached to my pc for storage. Yerterday I could access this disk with no problems and
it showed the folders and files as expected.
I shut down the pc last noght, and this mornoing when I booted up I could not access the USB HDD.
File manager states that the disk is empty, all my data has disappeared. AOMEI Partition Assistant shows
that the file system on the disk has changed from NTFS (yseterday) to FAT32. I gather that this is the problem,
that FAT32 will not handle disks of this side. Can anyone give me anyu idea how thois can occur ?
Has anyone tried to revert FAT32 to NTFS and regained the data ? I do of course realise that this is a forlorn hope,
but is rthere anything at all that I can do ?
I would be grateful for any advice.
TIA
Just for fun, the normal 64K max cluster size on Windows 10,
was changed to support clusters up to 1MB. Windows 7 and Windows 8
do not support this, and I do not recommend selecting such an option
if you found that in some NTFS preparation menu.
Now, imagine, secondly, that the disk is GPT, which makes sense.
This removed the 32 bit partition entry limitations, and allows larger partitions.
OK, then what about FAT32 ? It has a cluster size appropriate for
its maximum partition of 2.2TB. But what defines the maximum
cluster choice on FAT32 ? Is it the 2.2TB limit (which it probably
does not sense directly, hard to say). Or could it support larger
than 2.2TB on a GPT disk ? Dunno, really.
Windows itself, only "encourages" a partition change from FAT32 to NTFS.
It also selects a particularly small cluster size for this change, if
a user requests such a change. There is no software to go in the opposite direction. Just as the current OSes provide MBR2GPT.exe as a utility, which will take a legacy MSDOS partitioned disk and make it into a GPT disk.
The utility does not go in the opposite direction. A 6TB disk would be GPT,
and the Sector 0 four entry partition table, would have a "protective 0xEE partition of size 2.2TB" to cover the disk and prevent WinXP from making partitions in there. That partition entry must not be removed, or an older
OS could make a real mess.
The utility "testdisk" can compute a new MBR (and presumably in the year 2025, a new GPT table). It does a scan of the disk from sector 0, and it looks at particular offsets, for a valid first sector.
https://en.wikipedia.org/wiki/TestDisk
https://www.cgsecurity.org/wiki/TestDisk_Download <=== can spot the location of partitions, after a fashion
If you replace the MBR, that changes the file system type filed to something. But it does not change the PBR (the file system header, which is the first sector in
the partition). And I think that has a text string that defines
the filesystem type ("FAT32" or "NTFS") near the top.
You don't have to accept the declarations that TestDisk prepares.
I have used it a ton of times, just to "sniff" disks and see
what file systems are present. Note that there are a *large*
number of fake header sectors on your average drive, so *never panic*
when TestDisk prepares a pure rubbish declaration.
But if one of the detected PBR looked like a 6TB NTFS, then you
would know where the proposed start of that partition is. Since this is a backup disk, you should not have to wait long for it to analyze information
at an offset of 1 megabyte or 2 megabytes or so.
OK, what other fun can we have ?
Linux has the ability to do 64-bit file pointers (duh), but it also
supports loopback mount and in addition, it takes an "offset parameter".
This allows you to take a disk with a damaged MBR and GPT primary and
GPT secondary partition tables, and execute a loopback mount
pointed right at /dev/sda, step out to the proposed beginning of
the partition... and see if it mounts. In other words, Linux can
mount a partition on a disk drive, without using the MBR or the GPT tables.
I have done this with an Acronis Capacity Manager prepared disk,
where the disk is MSDOS, but a partition lives above 2.2TB, and that
partition could be mounted in Linux with a loopback mount. That isn't automated, and you have to do that manually.
Using a hex editor, you can "look at" the PBR and see whether what
you see makes sense.
*******
So I wanted to see the volume label, what fun. I thought this would be easy. No.
https://superuser.com/questions/1521246/where-does-ntfs-store-the-label-of-a-partition
And the scary part is, it worked. The test partition is my 682GB shared partition. I went to offset hex 0xC0000000 (that's with respect to the beginning
of the partition) and see a File0. At 0xC0000C00 I look down a bit and see $.V.o.l.u.m.e and then further down S.H.A.R.E.D :-) That's the volume name.
The volume name at partition offset 0xC0000D40. The partition is big enough, and being an SSD, it's never been defragmented and moved around. That's why $MFT is
still there. On your hard drive, you would need to do the individual steps
to determine what the offset should be. I got lucky on mine. The naive calculation
worked.
So there are a few tools for looking around.
Once Linux has the partition mounted, you should be able to copy all the files off.
And that's assuming whatever "accident" happened, hasn't trashed the $MFT file table.
Linux will tell you whether $MFT and $MFTMIRR agree or not.
Summary: Start with TestDisk and see what a scan shows.
See if it can collect the info for a new MBR.
You won't necessarily be using the info it collects, and you can press ctrl-C to quit any time.
But the location of the partition, may be useful for a manual mount and recovery.
and whatever third party software did this, must immediately be removed from the computer :-/
Paul
--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)