Description of problem: mkfs.fat reports Bad short file name() on a FAT32 formatted EFI System partition, but doesn't repair it, error persists. Version-Release number of selected component (if applicable): dosfstools-3.0.26-1.fc20.x86_64 How reproducible: Always on this particular volume. Steps to Reproduce: 1. mkfs.fat -av Actual results: # fsck.fat -av /dev/sda1 fsck.fat 3.0.26 (2014-03-07) Checking we can access the last sector of the filesystem Boot sector contents: System ID "mkfs.fat" Media byte 0xf8 (hard disk) 512 bytes per logical sector 512 bytes per cluster 32 reserved sectors First FAT starts at byte 16384 (sector 32) 2 FATs, 32 bit entries 1613312 bytes per FAT (= 3151 sectors) Root directory start at cluster 2 (arbitrary size) Data area starts at byte 3243008 (sector 6334) 403266 data clusters (206472192 bytes) 63 sectors/track, 255 heads 2048 hidden sectors 409600 sectors total / Bad short file name (). Auto-renaming it. Renamed to Reclaiming unconnected clusters. Checking free cluster summary. /dev/sda1: 14 files, 19388/403266 clusters Expected results: I'm not sure what () refers to. Seems like since it's saying it's being renamed that it wouldn't be a problem when running fsck again, but it's persistently reported as if it isn't being renamed. And also "Renamed to" reads like the rest is truncated. Additional info:
Oops. fsck.fat -av for the repair. The volume was originally created with mkdosfs -F 32 -n EFI /dev/sda1
I am unable to reproduce, could you provide image of the filesystem causing this?
Created attachment 876997 [details] ESPbadshort.img.xz # dd if=/dev/sda1 of=ESPbadshort.img # xz -z -e -v ESPbadshort.img
Thanks.
This is regression introduced in dosfstools-3.0.26. It seems to work with dosfstools-3.0.25.
(In reply to Jaroslav Škarvada from comment #5) > This is regression introduced in dosfstools-3.0.26. It seems to work with > dosfstools-3.0.25. I get the same with all my USB sticks. This did not happen with 3.0.25.
I also get the "Bad Short File Name" error message on my Fedora-20 system. To correct this bug I can run an older fsck version or re-format my/dev/sda1 (efi_sys) partition without forcing a fat-32 format via the -F 32 option. mkfs.vfat -v /dev/sda1 ..this works by letting mkfs decide if filesystem should be FAT12 FAT16 or FAT32 mkfs.vfat -v -F 32 /dev/sda1 ..this causes "fsck" to report "Bad short file name ()." Note: I decided to leave my /dev/sda1 (efi_sys) partition force formated to FAT32 because this seems to be in keeping with the UEFI specs & its 512K size should meet fat32 minimum partion size "EFI encompasses the use of FAT32 for a system partition, and FAT12 or FAT16 for removable media." I think fat32 defaults to 4K cluster size & also requires a minimum number of clusters. If this is true then forcing a small efi_sys partition to be formated Fat32 may only be possible by reducing the cluster size. --This could be the reason newer versions of fsck.vfat prints out the Bad Short File message.
Bit off-topic: We probably need a UEFI specific flag for mkfs.vfat/mkdosfs, because technically the UEFI spec differentiates between FATx and EFI file system: "The definition of the EFI file system will be maintained by specification and will not evolve over time to deal with errata or variant interpretations in OS file system drivers or file system utilities." It also says "The rules defining the relationship between media size and FAT variants is defined in the specification for the EFI file system." But I haven't been able to find that specification.
Got the same error on an NON EFI partition using Fedora 20.
I get the same error when using mkfs.vfat and fsck.vfat on an sd-card in the sd-card slot of a Thinkpad T520.
(In reply to Mike FABIAN from comment #10) > I get the same error when using mkfs.vfat and fsck.vfat on an sd-card > in the sd-card slot of a Thinkpad T520. On Fedora 20.
This bug was caused by non initialized "lcase" for the root directory and if it happened to have the flag FAT_NO_83NAME set, the new check in version 3.0.26 would output the "bad short file name" message. This bug is fixed in version 3.0.27 by this commit by Andreas Bombe: https://github.com/dosfstools/dosfstools/commit/82076b64ccc1bd18d854982f9c01d369a665ff65
(In reply to Alexis Murzeau from comment #12) > This bug was caused by non initialized "lcase" for the root directory and if > it happened to have the flag FAT_NO_83NAME set, the new check in version > 3.0.26 would output the "bad short file name" message. > > This bug is fixed in version 3.0.27 by this commit by Andreas Bombe: > https://github.com/dosfstools/dosfstools/commit/ > 82076b64ccc1bd18d854982f9c01d369a665ff65 Thanks for info, I will cherry-pick the commit.
dosfstools-3.0.27-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/dosfstools-3.0.27-1.fc21
dosfstools-3.0.27-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/dosfstools-3.0.27-1.fc20
Package dosfstools-3.0.27-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dosfstools-3.0.27-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-15099/dosfstools-3.0.27-1.fc21 then log in and leave karma (feedback).
dosfstools-3.0.27-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
dosfstools-3.0.27-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
verified with dosfstools-3.0.27-1.fc20.x86_64