Description of problem:


Version-Release number of selected component (if applicable): 
fsck from util-linux 2.25.2
fsck.fat 3.0.27 (2014-11-12)

How reproducible:
Always

Steps to Reproduce:

Find an SD card with vfat that needs some changes from fsck.

Without -r, both fsck and fsck.vfat default to doing nothing:


fsck /dev/sdb1
fsck from util-linux 2.25.2
fsck.fat 3.0.27 (2014-11-12)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 1
Leaving filesystem unchanged.


fsck.vfat /dev/sdb1
fsck.fat 3.0.27 (2014-11-12)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 1
Leaving filesystem unchanged.

The man page for fsck.vfat includes:

       -r  Interactively  repair  the filesystem. The user is asked for advice
           whenever there is more than one approach to fix an inconsistency.

The man page for fsck includes:

       -r     Interactively repair the  filesystem  (ask  for  confirmations).

However, -r works for fsck.vfat

fsck.vfat -r /dev/sdb1
fsck.fat 3.0.27 (2014-11-12)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 1
Perform changes ? (y/n)


while it does not work for plain fsck:

fsck -r /dev/sdb1
fsck from util-linux 2.25.2
fsck.fat 3.0.27 (2014-11-12)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 1
Leaving filesystem unchanged.


Although not all fsck filesystem types support -r, I expect that since fsck.vfat *does* support -r, plain fsck should pass the -r to fsck.vfat, and it obviously doesn't.

I had this problem in Mageia 4 as well.




Reproducible: 

Steps to Reproduce: