Partially damaged usb flash drive partition, rescued by testdisk

[commandline]

Dear,

This post more to document and discuss, learn than anything else. Background: the usb stick had been 'painted' with many layers of nail polish by an artist who wanted to make it into a present. As such i felt it was worth the effort and an interesting experience.

When asked to look into why an USB stick could not be used anymore i ran into a number of bizarre events. Eventually resorting to testdisk and running Analyse my suspicion was confirmed this stick was somehow damaged.

Before: The original pictures are on a portable usb hdd drive attached to a mac, the usb stick is as purchased. Both on an Apple OSX machine and a MS Windows machine it was found the stick would not accept the pictures as before. Every app i tried said the stick was a 64GB FAT32 filesystem. I assume there is where things went wrong. I tihnk to have seen this once before where an Apple screws up the filesystem since to OSX FAT32 cannot hold such a large size volume (64GB)

Initial actions performed were repartitioning, on each occassion this resulted in a success-fail condition with recurring i/o error notification. Initally on OSX (High Sierra) later on Linux. Multiple repartitioning attempts on both OSX and Linux failed. Somehow showing historical attempts for different filesystems present depending on what tool was used. This could be one tool finding ntfs, another ext4, another hpfs. Partitions could also "loose" information after a reboot.

Eventually, after many partitioning attempts on a Linux system (gdis, cfdisk, parted, testdisk) I decided the have testdisk wipe and create an MBR. Bizarre to find after reboot it showed a GPT table as was attempted before. Now using testdisk to create a partition was considered, which again worked, then failed. More attempts, rebooting etc to no avail.

Either way, eventually, i ran analyse again. Somehow, now it stopped at 75% and testdisk was unresponsive. Next i decided to use gdisk to create the partition from 0%-70% and found it worked. No more issues. No i/o errors or anything. Mutiple tests later, still stable at +40GB out of 64GB.


Summary: Now i felt like i eventually had a success but not a solid approach. At one point i suspected some malware on the USB Flash drive, maybe even in the firmware. Once i managed to reduce the volume size and it worked stable i kind of let go of that idea.

Question is obviously what program i could have used to find this issue.
It is probaly against the grain of the author's intent but partitioning could be extended as a separate functionality imho.
Maybe also some speedy analytics to simply inspect and report on garbled volume structures.
In the end, if it were not for the analysis halting at 75% i would not have guessed a functional volume size that easily.

I'd love to hear from you.

[recuperation]

Dear,

This post more to document and discuss, learn than anything else. Background: the usb stick had been 'painted' with many layers of nail polish by an artist who wanted to make it into a present. As such i felt it was worth the effort and an interesting experience.

When asked to look into why an USB stick could not be used anymore i ran into a number of bizarre events. Eventually resorting to testdisk and running Analyse my suspicion was confirmed this stick was somehow damaged.

Before: The original pictures are on a portable usb hdd drive attached to a mac, the usb stick is as purchased. Both on an Apple OSX machine and a MS Windows machine it was found the stick would not accept the pictures as before.

This is where we don't need to read ahead anymore.
The recipe is very simple: Try to duplicate the stick that became read/only.
Copy the copy a 2nd time and use Testdisk or Photorec if necessary.

Every app i tried said the stick was a 64GB FAT32 filesystem. I assume there is where things went wrong. I tihnk to have seen this once before where an Apple screws up the filesystem since to OSX FAT32 cannot hold such a large size volume (64GB)

Initial actions performed were repartitioning, on each occassion this resulted in a success-fail condition with recurring i/o error notification. Initally on OSX (High Sierra) later on Linux. Multiple repartitioning attempts on both OSX and Linux failed. Somehow showing historical attempts for different filesystems present depending on what tool was used. This could be one tool finding ntfs, another ext4, another hpfs. Partitions could also "loose" information after a reboot.

Eventually, after many partitioning attempts on a Linux system (gdis, cfdisk, parted, testdisk) I decided the have testdisk wipe and create an MBR. Bizarre to find after reboot it showed a GPT table as was attempted before. Now using testdisk to create a partition was considered, which again worked, then failed. More attempts, rebooting etc to no avail.

Either way, eventually, i ran analyse again. Somehow, now it stopped at 75% and testdisk was unresponsive. Next i decided to use gdisk to create the partition from 0%-70% and found it worked. No more issues. No i/o errors or anything. Mutiple tests later, still stable at +40GB out of 64GB.


Summary: Now i felt like i eventually had a success but not a solid approach. At one point i suspected some malware on the USB Flash drive, maybe even in the firmware. Once i managed to reduce the volume size and it worked stable i kind of let go of that idea.

Trying to write on assumably broken USB stick without having already read it out is not a good idea.

Question is obviously what program i could have used to find this issue.

There is no program to tell you that fooling around with a obviously broken device might end in the destruction of valuable data.

It is probaly against the grain of the author's intent but partitioning could be extended as a separate functionality imho.

I won't even have to ask Christophe Grenier to know that he won't do that. Furthermore Testdisk is partioning based on its finding that you have to agree to.

Maybe also some speedy analytics to simply inspect and report on garbled volume structures.

The quick search fills your log file. It gives you detailed information. Once you try to look into a partition found you are responible to decide to consider it as a hit or to drop the partition.

In the end, if it were not for the analysis halting at 75% i would not have guessed a functional volume size that easily.

For diagnosis run smartmontools.
For duplication run ddrescue.
For partitioning use parted or GParted.
To repair a faulty partition run chkdsk under Windows.




I'd love to hear from you.
[/quote]

[commandline]

Dear recuperation

Thanks for your informative reply. I was not asking for a procedure. The data on the stick was not required to be salvaged. I have not used windows in any circumstance here as the post clearly illustrates.

What i was actually asking for was software which could help me reliably diagnose what could have gone wrong. It was my distinct impression given enough background the stick could have been repaired 100%. My assumption is the lackluster support for FAT32 on OSX and potentially some accidental actions by users making it worse had created a very weird partition table ... or something else. At one point i considered a malicious USB drive or a broken controller firmware.

Either way, the stick appears to function fine at 70% partition size. My main curiosity here is to learn what could have caused this and how to diagnose the root cause.

[recuperation]

Dear recuperation

Thanks for your informative reply. I was not asking for a procedure. The data on the stick was not required to be salvaged. I have not used windows in any circumstance here as the post clearly illustrates.

What i was actually asking for was software which could help me reliably diagnose what could have gone wrong.

You will never get this kind of software. Even manual examination won't do it. You may understand the extent of dammage but not the cause.

It was my distinct impression given enough background the stick could have been repaired 100%.

I simply replace dubious storage because of the time needed. I can only judge from a software viewpoint. Keep in mind that your repair time has a price.

My assumption is the lackluster support for FAT32 on OSX and potentially some accidental actions by users making it worse had created a very weird partition table ... or something else. At one point i considered a malicious USB drive or a broken controller firmware.

Either way, the stick appears to function fine at 70% partition size. My main curiosity here is to learn what could have caused this and how to diagnose the root cause.

I strongly support your curiosity but I assume even a professional lab could not tell you the reason.