What has been your experience with this command? fsck.vfat

Joined
Jun 24, 2023
Messages
58
Reaction score
48
Credits
695
I have been concerned about trying this command "fsck.vfat" on my FAT formatted drives. My concern is that it might not do as good of a job as running Windows with the chkdsk command.

Do you have any personal experience with this command?

Here is the manual page from my Linux Mint 22.3 XFCE system:

Code:
FSCK.FAT(8)                                                                 System Manager's Manual                                                                 FSCK.FAT(8)

NAME
       fsck.fat - check and repair MS-DOS FAT filesystems

SYNOPSIS
       fsck.fat [OPTIONS] DEVICE

DESCRIPTION
       fsck.fat verifies the consistency of MS-DOS filesystems and optionally tries to repair them.

       The following filesystem problems can be corrected (in this order):

       •   FAT contains invalid cluster numbers.  Cluster is changed to EOF.

       •   File's cluster chain contains a loop.  The loop is broken.

       •   Bad clusters (read errors).  The clusters are marked bad and they are removed from files owning them.  This check is optional.

       •   Directories with a large number of bad entries (probably corrupt).  The directory can be deleted.

       •   Files . and .. are non-directories.  They can be deleted or renamed.

       •   Directories . and .. in root directory.  They are deleted.

       •   Bad filenames.  They can be renamed.

       •   Duplicate directory entries.  They can be deleted or renamed.

       •   Directories with non-zero size field.  Size is set to zero.

       •   Directory . does not point to parent directory.  The start pointer is adjusted.

       •   Directory .. does not point to parent of parent directory.  The start pointer is adjusted.

       •   . and .. are not the two first entries in a non-root directory.  The entries are created, moving occupied slots if necessary.

       •   Start cluster number of a file is invalid.  The file is truncated.

       •   File contains bad or free clusters.  The file is truncated.

       •   File's cluster chain is longer than indicated by the size fields.  The file is truncated.

       •   Two  or  more files share the same cluster(s).  All but one of the files are truncated.  If the file being truncated is a directory file that has already been read,
           the filesystem check is restarted after truncation.

       •   File's cluster chain is shorter than indicated by the size fields.  The file is truncated.

       •   Volume label in root directory or label in boot sector is invalid.  Invalid labels are removed.

       •   Volume label in root directory and label in boot sector are different.  Volume label from root directory is copied to boot sector.

       •   Clusters are marked as used but are not owned by a file.  They are marked as free.

       Additionally, the following problems are detected, but not repaired:

       •   Invalid parameters in boot sector

       When fsck.fat checks a filesystem, it accumulates all changes in memory and performs them only after all checks are complete.  This can be disabled with the -w option.

       Two different variants of the FAT filesystem are supported.  Standard is the FAT12, FAT16 and FAT32 filesystems as defined by Microsoft and widely used  on  hard  disks
       and removable media like USB sticks and SD cards.  The other is the legacy Atari variant used on Atari ST.

       There  are some minor differences in Atari format: Some boot sector fields are interpreted slightly different, and the special FAT entries for end-of-file and bad clus‐
       ter can be different.  Under MS-DOS 0xfff8 is used for EOF and Atari employs 0xffff by default, but both systems recognize all values from 0xfff8–0xffff as end-of-file.
       MS-DOS uses only 0xfff7 for bad clusters, where on Atari values 0xfff0–0xfff7 are for this purpose (but the standard value is still 0xfff7).

OPTIONS
       -a  Automatically repair the filesystem.  No user intervention is necessary.  Whenever there is more than one method to solve a problem, the least destructive  approach
           is used.

       -A  Select  using  the  Atari  variation  of  the FAT filesystem if that isn't active already, otherwise select standard FAT filesystem.  This is selected by default if
           mkfs.fat is run on 68k Atari Linux.

       -b  Make read-only boot sector check.

       -c PAGE
           Use DOS codepage PAGE to decode short file names.  By default codepage 850 is used.

       -d PATH
           Delete the specified file.  If more than one file with that name exist, the first one is deleted.  This option can be given more than once.

       -f  Salvage unused cluster chains to files.  By default, unused clusters are added to the free disk space except in auto mode (-a).

       -F NUM
           Specify FAT table NUM for filesystem access.  By default value 0 is assumed and then the first uncorrupted FAT table is chosen.  Uncorrupted means  that  FAT  table
           has valid first cluster.  If default value 0 is used and all FAT tables are corrupted then fsck.fat gives up and does not try to repair FAT filesystem.  If non-zero
           NUM  value  is  specified then fsck.fat uses FAT table NUM for repairing FAT filesystem.  If FAT table NUM has corrupted first cluster then fsck.fat will repair it.
           In any case, if FAT filesystem has more FAT tables then repaired content of chosen FAT table is copied to other FAT tables.  To repair corrupted first cluster it is
           required to call fsck.fat with non-zero NUM value.

       -l  List path names of files being processed.

       -n  No-operation mode: non-interactively check for errors, but don't write anything to the filesystem.

       -p  Same as -a, for compatibility with other *fsck.

       -r  Interactively repair the filesystem.  The user is asked for advice whenever there is more than one approach to fix an inconsistency.  This is the default  mode  and
           the option is only retained for backwards compatibility.

       -S  Consider short (8.3) file names with spaces in the middle to be invalid, like previous versions of this program did.  While such file names are not forbidden by the
           FAT  specification,  and  were never treated as errors by Microsoft file system checking tools, many DOS programs are unable to handle files with such names.  Using
           this option can make them accessible to these programs.

           Short file names which start with a space are considered invalid regardless of this option's setting.

           Previous versions of this program exceptionally treated EA DATA. SF and WP ROOT. SF as valid short names; using this option does not preserve that exception.

       -t  Mark unreadable clusters as bad.

       -u PATH
           Try to undelete the specified file.  fsck.fat tries to allocate a chain of contiguous unallocated clusters beginning with the start cluster of the  undeleted  file.
           This option can be given more than once.

       -U  Consider  lowercase  volume  and boot label as invalid and allow only uppercase characters.  Such labels are forbidden by the FAT specification, but they are widely
           used by Linux tools.  Moreover MS-DOS and Windows systems do not have problems to read them.  Therefore volume and boot labels with lowercase characters are by  de‐
           fault permitted.

       -v  Verbose mode.  Generates slightly more output.

       -V  Perform  a verification pass.  The filesystem check is repeated after the first run.  The second pass should never report any fixable errors.  It may take consider‐
           ably longer than the first pass, because the first pass may have generated long list of modifications that have to be scanned for each disk read.

       --variant TYPE
           Create a filesystem of variant TYPE.  Acceptable values are standard and atari (in any combination of upper/lower case).  See above under DESCRIPTION for  the  dif‐
           ferences.

       -w  Write changes to disk immediately.

       -y  Same as -a (automatically repair filesystem) for compatibility with other fsck tools.

       --help
           Display help message describing usage and options then exit.

EXIT STATUS
       0   No recoverable errors have been detected.

       1   Recoverable errors have been detected or fsck.fat has discovered an internal inconsistency.

       2   Usage error.  fsck.fat did not access the filesystem.

FILES
       fsck0000.rec, fsck0001.rec, ...
           When recovering from a corrupted filesystem, fsck.fat dumps recovered data into files named fsckNNNN.rec in the top level directory of the filesystem.

BUGS
       •   Does not remove entirely empty directories.

       •   Should give more diagnostic messages.

       •   Undeleting files should use a more sophisticated algorithm.

SEE ALSO
       fatlabel(8), mkfs.fat(8)

HOMEPAGE
       The home for the dosfstools project is its GitHub project page.

AUTHORS
       dosfstools were written by Werner Almesberger, Roman Hodek, and others.  Current maintainers are Andreas Bombe and Pali Rohár.

dosfstools 4.2                                                                     2021-01-31                                                                       FSCK.FAT(8)
 


I'd generalise a bit in that it's safest to use the tools of the system the individual filesystem is created with. If a vfat was created on Linux, safest is to use Linux tools to repair, and vice versa.

Just for checking filesystem integrity (not repairing), it should not matter.
 
What I've learnt...fsck should only be run on an unmounted Linux Drive.
Vfat isn't Linux.
1775607035838.gif


I can understand people coming from windoze are paranoid about corrupt system files as it happens all the time but that's not the case in Linux.

In 11 years of running Linux Mint..do you know how many times I've run fsck from the Live Session...once and that was to see if it worked because I've never had any problems.
1775607692173.gif
 
A command you are not familiar with and perhaps dont really have a need to run it.....
have been concerned about trying this command etc
What could possibly go wrong.

Good thing that you at least asked before running it.
 
I have been concerned about trying this command "fsck.vfat" on my FAT formatted drives. My concern is that it might not do as good of a job as running Windows with the chkdsk command.

Do you have any personal experience with this command?
I have no experience with the command fsck.vfat, but it's a testable matter.

The canonical means of dealing with repairing MS filesystems is to use MS tools made for that specific purpose, as mentioned by @CaffeineAddict and @Trml.

However, if one is interested in the applicability of linux tools that purport to be able to make similar repairs to MS filesystems, a first step might be to ask: does MS accept a usb with FAT32 formatted by linux tools without issue? If a linux formatted usb cannot pass that basic hurdle, then one suspects the more advanced tools for repair may not be optimal, or even functional, to say the least.

On the other hand, if MS recognises the linux formatted FAT32 usb without issue, then using the linux repair tools might be an option to try on a usb with a corrupted FAT32 filesystem. There's a possible failsafe with this latter check in that if the linux tools fail, the MS tools should be able to succeed since that is what they are designed to do.

The linux formatting tools that can achieve the formatting are fdisk and mkfs.fat -F 32. Unfortunately I have no current relevant contact with the MS universe, so no need to use these linux tools. I can however, at least say that in the past, linux formatted usbs with data, having been written to usbs formatted with FAT32 filesystems that I've provided to MS users, were used without issues on MS machines, but it's a very small sample of users a long time ago.
 
does MS accept a usb with FAT32 formatted by linux tools without issue?

I can help with this one. I fairly regularly give away USB thumb drives with stuff on them. They're formatted with FAT32, or sometimes exFAT. Nobody has any problems with them, and they're certainly not using Linux.
 
If I were going to check the file system (which I never do) of lets say a Flash Drive I'd use the Gnome Disk Utility.

1775692968227.png

but that's just me.
1775693292308.gif
 
If I were going to check the file system (which I never do) of lets say a Flash Drive I'd use the Gnome Disk Utility.
The Gnome Disk Utility is just a GUI front end that leads to calling the fsck.vfat for FAT filesystems. It adds no extra functionality to the file checking, though it can be a convenience for desktop users.
 
Some years ago I did try a check tool that I found in gparted. As I remember the option warned me that it could cause problems, and it did mess up something on the drive! While the USB drive was still readable and seemed fine on my linux system, as soon as I tried plugging it into my windows 7 laptop, one could tell it was messed up. The Windows 7 OS couldn't even see it anymore. I think whatever it did, may have messed up the firmware or something. I don't know. I ended up finding a windows tool to get the USB usable again. I haven't tried to do anymore checking of the FAT file system in linux. I think gparted called on fsck.vfat.
 
When find a flash drive that I can test without worry, I will try that!

In Linux...not much goes wrong...Flash Drives...internal Drives...External Drives fail but that's life. If you pull a Flash Drive out without ejecting it safely...you might be able to repair the file system with the Disk Utility.

If that doesn't work...you need to re-format it. I've never checked the file system on Flash Drives or external Drives as there's no need to.

If you're using an internal SSD...it doesn't hurt to run the SMART test in the Disk Utility every 6 mths or so.

1775774222933.gif
 
In Linux...not much goes wrong...Flash Drives...internal Drives...External Drives fail but that's life. If you pull a Flash Drive out without ejecting it safely...you might be able to repair the file system with the Disk Utility.

If that doesn't work...you need to re-format it. I've never checked the file system on Flash Drives or external Drives as there's no need to.

If you're using an internal SSD...it doesn't hurt to run the SMART test in the Disk Utility every 6 mths or so.

View attachment 31294

Not often, but once in a blue moon, I accidentally pull a drive out without ejecting it first. Then I attach it a Windows computer, the Windows computer says it wasn't ejected properly, and then recommends that I check it. I run the check and usually it says nothing wrong. But at least it checked the file system. I got too much data on my drives to just reformat and re copy everything, just cause it got pulled. It could take me an hour to put all that stuff back on a drive. Anyways another thing that can happen to me is that I will be using my computer and the electric goes off. That also can give me a reason to want to do a file system check on the drive.
 
Golden rule number one...always eject a Flash Drive or External Drive safely.

I have my Tower connected to a power surge protection board...which cost about $50...my Tower costs much more.
1776042174769.gif
 
Golden rule number one...always eject a Flash Drive or External Drive safely.

I have my Tower connected to a power surge protection board...which cost about $50...my Tower costs much more. View attachment 31344

If you are a human being and you are in a rush to get something done because time is limited, then you will accidentally pull a drive without ejecting it. That is why they call an issue like that, a brain fart. Some people have more of them than others.

I just thought of this. This don't normally happen but it can and does sometimes. Sometimes the OS freezes up, and then you got to force the computer to shutdown, and when that happens you can't eject the USB drive either.
 
Last edited:


Follow Linux.org

Staff online

Members online


Top