I don't typically post to engineering but I need help with a USB drive. First off, I have a USB, a Sahara 128mb, that once became unusable on windows machines, and I thought it was dead. Yet I kept it for about 10 or more years to-date. Recently, I plugged it into a linux machine and I saw magic, it worked. I never changed the filesystem types, or anything.
Now, I have a newer SanDisk 16GB USB that I actually did nothing to except try to flash an OS onto it and it failed on its own. It has two partitions, one already has another OS written to it. I am not sure if the disk was burnt during the write of the second OS. This was a normal write by something like rufus/unetbootin (which might matter, as that could be the culprit). But now, most operations on the USB will return an IO error. I can read and actually use (boot from the USB) the first partition to install that OS. But when I try to delete the data on the USB, or the first partition, it fails and automatically ejects.
The second partition has a newer version of an/the OS I wish to write to the disk/partition. Initially, it allowed me to delete the files on the disk but once reaching a certain point, the writes fail and it ejects itself. My problem is that everything seems intact. I do not know how the disk was locked or became write protected. I tried a few utilities to remove this, and it seems to respond but nothing has changed.
I read about MBR and GPT, and there is a clue there. When the GPT is present or readable via gdisk, my partitions are intact, when both are present, MBR shows nothing and the GPT table is intact. So the clue is a mismatch of some sort. And regardless, the data is intact. I had another HDD 500GB disk (probably SAMSUNG) do a similar thing, I was doing 'nothing' for hours, then I ran gdisk with disks utility side by side, and started to see the changes I was making to my disk.
It turns out that with the HDD disk, I was doing what I wanted to do but gdisk was throwing gang signs, claiming that my operations failed. Once I caught this, I fixed it, and stopped working blindly.
Unfortunately, when my disk was mismatched again, on the SanDisk USB that prompted me to open this question... I tried a similar thing or solution as that which helped me with the other HDD disk. I can for example see the partition deletion take place, but before it is committed the USB disk fails with an IO error, and ejects itself. So, when it is inserted again, it is as if I never actually did a thing. So now the operations are failing.
Any ideas on how I can fix my disk? At this point, I wish to even suspect the tools that I am working with. The disk is readable on windows very briefly but any attempt to access its data or perform administrative disk utility operations causes it to eject. Windows is not very descriptive. I suspect that it is fried, can this theory be tested, or how do you test for a fried USB, when it seems or appears to be working? And, how do you just nuke the USB disk to a factory state? I think that once I do that I will be able to separate healthy sectors from dead/corrupted ones. I will not miss the data on it at this point, as it is easy enough to loan an ISO from a friend or download it from the internet and write it to the disk again.
This will be a very important lesson for me in disk management, especially if I can develop a true method to test for dead drives, rather than ones not being supported by my system. Though this could very well be one and the same thing.
I hope engineers will help. There was no need to re-post Linux commands, you know them, I probably read them off a reference manual, on stack overflow, or someplace else on the internet.
Reference: something like what this person wanted https://www.vbforums.com/showthread.php?613245-how-to-fry-a-flash-drive or gravitating towards the level of work suggested. There are many references to switching OS, as different ones have different capabilities for manipulating hardware for obvious reasons, hardware is expensive. I don't wish to fry it, just reset with no regard for data, if manipulating data pins can help, I wish to learn that, and research safety of the procedure.
There was no need to repost linux commands, you know them
... that is not a very useful description of what you did $\endgroup$