Bug 438792

Summary: dosfsck truncates large files (close to 4Gb boundery) to 0 bytes
Product: [Fedora] Fedora Reporter: Peter Koek <p.koek2>
Component: dosfstoolsAssignee: Stepan Kasal <kasal>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 9CC: daniel, lex.lists
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-03-05 19:40:52 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Peter Koek 2008-03-25 06:37:44 EDT
Description of problem:
dosfsck truncated large files (close to 4Gb boundary) to 0 bytes.

Version-Release number of selected component (if applicable):
I have 2.11-8, but all versions have this problem.

How reproducible:
Create a file with size 4294966784 bytes (4 GB - 512 bytes) on a FAT32 file
system. (Files of this size are created by Acronis Image tool, which I used
use command: dosfsck -a -v /dev/...
The previous created file is now truncated to 0 bytes !!!

Expected results:
This file size is allowed on a FAT32 file system, therefore it should NOT be
truncated to 0 bytes.

Additional info:
The problem is caused by a overflow in the calculation of the filesize. In case
of a large file the multiplication 65535 * 65535 results in 0, which is
incorrect. The Ubunto distro has fixed this issue by using "long long" values,
therefore a fixed can be found at there website. But I would like to see that
this bug will be resolved in Fedora also.

see bug report ubuntu:

Patch for dosfstools large files fix:
sources of dosfstools of Ubuntu:
Comment 1 Bug Zapper 2008-05-14 02:49:34 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 2 Daniel Baumann 2008-11-23 13:18:54 EST
This bug has been fixed upstream in 3.0.0 (when merging debian changes in it) and can be closed now.