fixing usb memory stick
July 18, 2021 3:51 PM Subscribe
I have a usb memory stick that is having issues accessing certain files. When I connect it to computer on the first try it says please insert disk into usb drive. I then pull it out and re insert and it says there's a problem with the disk and gives me the option to scan and repair. I've tried that and it doesn't fix the issues which are...some files won't open. Some will but others won't. If I try to do the command prompt chckdisk: f: /f /r /x is there a chance I will lose data on the memory stick? I may just bring it in to a place to repair it but that's expensive. Is the command prompt method different from the scan and repair basic method? Do you think it might fix the problem or at least not make it worse? Any other suggestsion? Thanks!
Memory sticks are relatively cheap. Get the data off the stick as suggested above and just get a new stick.
posted by cgg at 7:33 PM on July 18, 2021 [3 favorites]
posted by cgg at 7:33 PM on July 18, 2021 [3 favorites]
Seconding Aleyn on using PhotoRec: just dump what you can from it and sort through what it dumps. Some stuff may be beyond repair.
And yes, it's best to treat USB sticks as temporary storage, not forever storage. If it starts being anything close to weird, you can no longer trust it. Buy a bunch of sticks so you'll always have a spare, see if you can stick those files in the cloud somewhere.
posted by holgate at 9:06 PM on July 18, 2021 [1 favorite]
And yes, it's best to treat USB sticks as temporary storage, not forever storage. If it starts being anything close to weird, you can no longer trust it. Buy a bunch of sticks so you'll always have a spare, see if you can stick those files in the cloud somewhere.
posted by holgate at 9:06 PM on July 18, 2021 [1 favorite]
Congratulations. You've just learned the valuable lesson that digital information doesn't really exist until you can put your hands on at least two identical copies, and it's only cost you some of the contents of one little USB drive.
Some people don't get the opportunity to learn this until years of irreplaceable memories have gone completely irretrievably to the great bit bucket in the sky.
Now would be a really good time to have a good think about where and on what you keep data you care about not losing, and putting in place strategies to make sure you have at least two copies of all of it on diverse media, preferably with at least one copy in a different building and at least one copy always offline so as to be inaccessible to ransomware.
Also endorsing what's been said above. If the stick was the only place where something important to you was stored, and you're now having trouble retrieving that stuff, then you absolutely do not want to be using tools that scan and "repair" that stick, GUI or command line or otherwise.
Best practice would be to use a reliable disk cloning tool to make a block-for-block copy of the stick as a disk image file, then use something like PhotoRec to scan the image file and retrieve whatever can be retrieved from that. Next best would be to run PhotoRec against the stick itself.
What must be avoided is using anything that tries to alter the stick's present contents in any way, because the chances of losing even more than has already been lost are very high.
The fact that you're asking this question suggests to me that you're unlikely to be justifiably confident in using these tools, and if what's on your stick really is important and really can't be retrieved from anywhere else then I recommend either paying for the time of somebody who is, or bringing yourself up to speed by playing with them on data you don't care about beforehand.
posted by flabdablet at 11:44 PM on July 18, 2021 [7 favorites]
Some people don't get the opportunity to learn this until years of irreplaceable memories have gone completely irretrievably to the great bit bucket in the sky.
Now would be a really good time to have a good think about where and on what you keep data you care about not losing, and putting in place strategies to make sure you have at least two copies of all of it on diverse media, preferably with at least one copy in a different building and at least one copy always offline so as to be inaccessible to ransomware.
Also endorsing what's been said above. If the stick was the only place where something important to you was stored, and you're now having trouble retrieving that stuff, then you absolutely do not want to be using tools that scan and "repair" that stick, GUI or command line or otherwise.
Best practice would be to use a reliable disk cloning tool to make a block-for-block copy of the stick as a disk image file, then use something like PhotoRec to scan the image file and retrieve whatever can be retrieved from that. Next best would be to run PhotoRec against the stick itself.
What must be avoided is using anything that tries to alter the stick's present contents in any way, because the chances of losing even more than has already been lost are very high.
The fact that you're asking this question suggests to me that you're unlikely to be justifiably confident in using these tools, and if what's on your stick really is important and really can't be retrieved from anywhere else then I recommend either paying for the time of somebody who is, or bringing yourself up to speed by playing with them on data you don't care about beforehand.
posted by flabdablet at 11:44 PM on July 18, 2021 [7 favorites]
Further to why chkdsk and friends are completely unsuitable tools for this use case: computer filesystems do a lot of internal bookkeeping to make sure that as new data gets written to them, it ends up in places where it can be retrieved on demand and where it won't overwrite other data previously written to that filesystem.
There are various kinds of damage that can be inflicted on on-disk filesystems that break those guarantees. Sometimes hardware failures are the cause of that damage, but more commonly it's updates to bookkeeping information that didn't actually get written out to the medium holding the filesystem before it got forcibly removed from the computer.
What chkdsk does (and what the GUI "find and fix errors" tool also does, by running chkdsk under the hood) is detect and attempt to correct inconsistencies in the filesystem's bookkeeping information. When chkdsk has finished "repairing" a disk, the only thing you can safely assume is that subsequent file creation and modification will happen in a way that doesn't result in new data overwriting old data except when that's explicitly what the system has instructed the filesystem to do.
In the process of "repairing" broken bookkeeping information, chkdsk sometimes has to make decisions about what to do with data blocks that seem to belong to more than one file. In general it will deal with this by assigning them to one of the files and removing them from the other(s). This is enough to get the filesystem into good enough shape that simply using it from then on won't cause compounding damage, but there's no guarantee at all that the decision chkdsk makes is actually the best one. If, as is common in these cases, the filesystem also contains damage not purely in its bookkeeping regions, the alterations that chkdsk makes can mean that otherwise completely recoverable data is either disconnected from the files in belongs to or even gets overwritten by chkdsk itself.
All of this is because chkdsk only understands filesystem bookkeeping information. It knows nothing about the internal structures of the various file formats that might exist in the filesystem and therefore the guesses it makes about which file any given block really belongs to are arbitrary and often wrong.
Photorec and similar tools make no attempt to correct bookkeeping information on the filesystems you run them against; in fact they make a point of making no modifications to the damaged filesystems whatsoever. They use such bookkeeping information as still exists as hints about what files exist and where, but mostly what they do is scan over the entire disk as if it were a huge pile of jigsaw puzzle pieces, and use knowledge about internal file formats to reassemble those pieces into files that make some kind of sense.
Chkdsk is the right tool to use if your aim is to return a disk drive to service, and you know what damaged it, are convinced that the damage is both minor and not caused by ongoing hardware failure, and are prepared to discover which files chkdsk has destroyed and restore those from other sources. It's essentially a shortcut past reformatting and restoring from backups and you usually need to do further work after running it. It is in no way a data recovery tool. Quite the opposite, in fact; it's a data pruning tool.
Running chkdsk is something of a desperation measure, kind of like boring a hole in your filesystem's skull to stop an intracranial bleed from doing further damage. That would make Photorec the equivalent of guided hypnosis to help it remember things it didn't know that it had forgotten.
Gnu ddrescue, the disk cloning tool I linked to above, has yet another purpose: it will do its best to make a block-for-block copy of the entire source medium, including all the broken bookkeeping and all the disk blocks that the original filesystem has marked as unused (possibly incorrectly so, depending on how it was damaged). Any blocks from the source that ddrescue can't read at all just get noted in the map file it keeps while copying and don't get written out to the copy, leaving "holes" to be dealt with by some other tool at some other time.
Ddrescue is the first tool I will always reach for in any kind of data recovery scenario, because failing hardware frequently keeps on failing and if I'm going to be making hundreds of read passes with a file recovery tool I'd rather be doing that over a clean and complete copy that probably won't be provoked into failing even more.
This is not such an issue with USB stick sources, because just reading those doesn't usually kill them. Writing even a single block to a failing USB stick can be enough to kill the whole thing, and chkdsk will certainly write something if you tell it to "fix errors".
posted by flabdablet at 1:24 AM on July 19, 2021 [4 favorites]
There are various kinds of damage that can be inflicted on on-disk filesystems that break those guarantees. Sometimes hardware failures are the cause of that damage, but more commonly it's updates to bookkeeping information that didn't actually get written out to the medium holding the filesystem before it got forcibly removed from the computer.
What chkdsk does (and what the GUI "find and fix errors" tool also does, by running chkdsk under the hood) is detect and attempt to correct inconsistencies in the filesystem's bookkeeping information. When chkdsk has finished "repairing" a disk, the only thing you can safely assume is that subsequent file creation and modification will happen in a way that doesn't result in new data overwriting old data except when that's explicitly what the system has instructed the filesystem to do.
In the process of "repairing" broken bookkeeping information, chkdsk sometimes has to make decisions about what to do with data blocks that seem to belong to more than one file. In general it will deal with this by assigning them to one of the files and removing them from the other(s). This is enough to get the filesystem into good enough shape that simply using it from then on won't cause compounding damage, but there's no guarantee at all that the decision chkdsk makes is actually the best one. If, as is common in these cases, the filesystem also contains damage not purely in its bookkeeping regions, the alterations that chkdsk makes can mean that otherwise completely recoverable data is either disconnected from the files in belongs to or even gets overwritten by chkdsk itself.
All of this is because chkdsk only understands filesystem bookkeeping information. It knows nothing about the internal structures of the various file formats that might exist in the filesystem and therefore the guesses it makes about which file any given block really belongs to are arbitrary and often wrong.
Photorec and similar tools make no attempt to correct bookkeeping information on the filesystems you run them against; in fact they make a point of making no modifications to the damaged filesystems whatsoever. They use such bookkeeping information as still exists as hints about what files exist and where, but mostly what they do is scan over the entire disk as if it were a huge pile of jigsaw puzzle pieces, and use knowledge about internal file formats to reassemble those pieces into files that make some kind of sense.
Chkdsk is the right tool to use if your aim is to return a disk drive to service, and you know what damaged it, are convinced that the damage is both minor and not caused by ongoing hardware failure, and are prepared to discover which files chkdsk has destroyed and restore those from other sources. It's essentially a shortcut past reformatting and restoring from backups and you usually need to do further work after running it. It is in no way a data recovery tool. Quite the opposite, in fact; it's a data pruning tool.
Running chkdsk is something of a desperation measure, kind of like boring a hole in your filesystem's skull to stop an intracranial bleed from doing further damage. That would make Photorec the equivalent of guided hypnosis to help it remember things it didn't know that it had forgotten.
Gnu ddrescue, the disk cloning tool I linked to above, has yet another purpose: it will do its best to make a block-for-block copy of the entire source medium, including all the broken bookkeeping and all the disk blocks that the original filesystem has marked as unused (possibly incorrectly so, depending on how it was damaged). Any blocks from the source that ddrescue can't read at all just get noted in the map file it keeps while copying and don't get written out to the copy, leaving "holes" to be dealt with by some other tool at some other time.
Ddrescue is the first tool I will always reach for in any kind of data recovery scenario, because failing hardware frequently keeps on failing and if I'm going to be making hundreds of read passes with a file recovery tool I'd rather be doing that over a clean and complete copy that probably won't be provoked into failing even more.
This is not such an issue with USB stick sources, because just reading those doesn't usually kill them. Writing even a single block to a failing USB stick can be enough to kill the whole thing, and chkdsk will certainly write something if you tell it to "fix errors".
posted by flabdablet at 1:24 AM on July 19, 2021 [4 favorites]
If this is a 1TB or 2TB stick, it's mostly like a fake that has been doctored to show a size that's not correct.
posted by Ferrari328 at 5:52 AM on July 19, 2021 [1 favorite]
posted by Ferrari328 at 5:52 AM on July 19, 2021 [1 favorite]
This thread is closed to new comments.
Do not try to "fix" the memory stick either. It has already demonstrated its unreliability to you and if what you're asking is if you can continue using it without it potentially eating your data in the future, the answer is a resounding no. It doesn't matter what commands you run, you will be rolling the dice on this drive from here on out. You will save yourself a lot of trouble and heartache by getting a new one.
In the future, also make sure that you "eject" the drive before removing it from your computer, as you can corrupt data or the drive itself if you don't.
posted by Aleyn at 4:11 PM on July 18, 2021 [9 favorites]