dosfstools 3.0.25 was released on January 17, fixing fsck errors on 64-bit. http://daniel-baumann.ch/software/dosfstools/ The exact ChangeLog entries are as follows: commit 21fe921 Author: Andrew Tridgell <tridge@samba.org> Date: Tue Jan 14 09:37:51 2014 +1100 Fixed remaining 64 bit build warnings. Some of these may be real bugs. Signed-off-by: Daniel Baumann <mail@daniel-baumann.ch> commit 9e3a2b1 Author: Andrew Tridgell <tridge@samba.org> Date: Tue Jan 14 09:25:28 2014 +1100 Prevent corruption of FAT during fsck on 64 bit platforms. unsigned long is 64 bit on x86-64, which means set_fat was writing two entries, which corrupts the next entry. This can cause loss of data in another file. I've backported these fixes to Mageia 3. Advisory: ---------------------------------------- The dosfsck command in dosfstools before 3.0.25 could cause corruption in FAT filesystems when used on 64-bit platforms. This has been fixed. References: http://daniel-baumann.ch/software/dosfstools/ ---------------------------------------- Updated packages in core/updates_testing: ---------------------------------------- dosfstools-3.0.16-1.1.mga3 from dosfstools-3.0.16-1.1.mga3.src.rpm Reproducible: Steps to Reproduce:
Hardware: i586 => x86_64
Testing complete mga3 64 Created some files on a vfat usb stick $ for (( i=100;i<200;i++ )) do echo "File ok" > /run/media/claire/USBSTICK/file$i; done $ cat /run/media/claire/USBSTICK/file* $ cat /run/media/claire/USBSTICK/file* | wc -l 100 Before ------ # dosfsck -vr /dev/sdd dosfsck 3.0.16 (01 Mar 2013) dosfsck 3.0.16, 01 Mar 2013, FAT32, LFN Logical sector size (56113 bytes) is not a multiple of the physical sector size. $ cat /run/media/claire/USBSTICK/file* $ cat /run/media/claire/USBSTICK/file* | wc -l 100 After ----- # dosfsck -vr /dev/sdd dosfsck 3.0.16 (01 Mar 2013) dosfsck 3.0.16, 01 Mar 2013, FAT32, LFN Logical sector size (56113 bytes) is not a multiple of the physical sector size. $ cat /run/media/claire/USBSTICK/file* $ cat /run/media/claire/USBSTICK/file* | wc -l 100 Nothing unusual to note, before or after.
Whiteboard: (none) => has_procedure mga3-64-ok
Is there
CC: (none) => stormi
Trying again: is there a way to reproduce the filesystem corruption? Testing mga3 32 in progress.
mga3 32 testing complete.
Whiteboard: has_procedure mga3-64-ok => has_procedure mga3-64-ok mga3-32-ok
(In reply to Samuel VERSCHELDE from comment #3) > Trying again: is there a way to reproduce the filesystem corruption? I think in general, fsck doesn't write to a filesystem unless it thinks it needs to (other than marking it as having been checked in some cases), so it might have to already be corrupted a bit to trigger this, but I'm not sure.
Advisory added
Whiteboard: has_procedure mga3-64-ok mga3-32-ok => has_procedure mga3-64-ok mga3-32-ok advisory
Update validated and advisory in SVN. Could sysadmin please push from core/updates_testing to core/updates.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Update pushed: http://advisories.mageia.org/MGAA-2014-0013.html
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED