1

I was recently trying to move some of my files on my USB drive (Kingston DT Elite G2) from NTFS ot FAT32 using a Linux Mint 19 system. What I did was:

  • make a FAT32 partition
  • copy some files from the NTFS partition to the FAT32 partition.

After doing this, both partitions were still readable by both Windows and Linux. However, after shrinking the NTFS partition and increasing the size of the FAT32 one, the FAT32 one could not be read by Windows anymore. I get a "You need to format the disk" message. The NTFS partition could still be read by Windows.

I then ran fsck /dev/sdb2 on the Linux system, which removed the dirty bit (which was set) and repaired a few files with an incorrect file length. (Note that fsck.fat was used, not fsck.ext.)

Even after running fsck, the issue still occurs. Windows Disk Management says the partition is RAW (unrecognized). Disk Management

However, the partition can even be read by some Windows programs. DiskInternals reads it as a no-name FAT32 partition without any errors (even though the partition has a name). DiskInternals

What can I do to make this partition readable by Windows Explorer again?

4
  • I don't understand the point of having two partitions and two different file systems in a 64GB (?) USB stick. Those typically are formatted as exFAT - natively supported in Windows, support needs to be installed for Linux -.
    – user931000
    Oct 29, 2018 at 16:41
  • 1
    So... your shrinking/extending process is failing in Linux. You corrected some of it and some of the bytes are obviously still off if some programs can correct it and others can't. Next time, do the expanding/shrinking in Windows and you'll be just fine. If you really want to figure it out, load up a hex editor and see what bytes are wrong after comparing it tot he spec and you can manually fix it yourself.
    – thepip3r
    Oct 29, 2018 at 16:44
  • @thepip3r I tried using Windows to do the shrinking/extending, but I got a cryptic Could not fill space error.
    – Zackary
    Oct 29, 2018 at 16:49
  • Then I was wrong before by saying to run it in Windows. Given the rest of what you said, it sounds as if the drive has some bad sectors (indicated by the corrections performed by fsck--and you did attempt-to and correct them or did you just scan for them?). And ultimately you could be seeing the early symptoms of a failing drive. Whatever vendor the drive is, download the HDD scan/fix util and see what it says. If you have important data on the drive, you should back it up ASAP in case of a failure event.
    – thepip3r
    Oct 29, 2018 at 17:51

1 Answer 1

0

This might be related to https://unix.stackexchange.com/q/410440/168301, where someone else ran into the same problem. A comment (which should be an answer) linked to https://bugzilla.gnome.org/show_bug.cgi?id=759916#c21:

In case it can help someone, here's the oneliner I've used to fix the broken FS on a USB key, based on the comments above:

$ echo -ne '\xeb\x58\x90' | sudo dd conv=notrunc bs=1 count=3
of=/dev/sdb1

Be careful to target the right partition (/dev/sdb1 in my case, probably something else in yours) and to first test the command line on a text file to make sure the hexadecimal is properly interpreted by your shell (the above works in ZSH, but with other shell, you might have to double the backslashes).

I ran this command in bash (not zsh), and it fixed a partition on my hard drive with the same issue (previously, Windows and testdisk couldn't recognize the filesystem on the partition). I didn't test on fish though.

I still think Linux's fsck.vfat needs to be changed to recognize and fix this error, and testdisk should ideally recognize this type of corrupted disk and restore it for you, and photorec shouldn't enter an infinite loop when trying to unformat this type of broken partition.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .