Bug#1001845: dosfstools: After a dirty unplug, fsck.vfat truncates 4GiB files to zero

[farblos]

Package: dosfstools
Version: 4.2-1
Severity: important
X-Debbugs-Cc: in.cog...@arcor.de

Dear Maintainer,

* What led up to the situation?

Had some troubles with an USB hub, during which a USB flash drive was
powered off without being unmounted cleanly. During my following
fsck run, fsck.vfat "offered" to truncate files of size (4GiB - 1) to
zero bytes. And does so, if let to.

* What exactly did you do (or not do) that was effective (or
ineffective)?

After hitting the issue twice with a "production" flash drive, I tried
to reproduce the issue on a different flash drive with the following steps:

# Ensure Gnome's (or whatever) auto-mounting is off to have
# better control over mount operations.

farblos@sappc2:~$ sudo mkfs.vfat -n "MCBACKUP" /dev/sda1
mkfs.fat 4.2 (2021-01-31)
farblos@sappc2:~$ udisksctl mount --block-device /dev/sda1
Mounted /dev/sda1 at /media/farblos/MCBACKUP

# Populate the flash drive with small files, just to have some
# contents (optional). Finally, create the one big file:

farblos@sappc2:~$ mkdir /media/farblos/MCBACKUP/documents
farblos@sappc2:~$ truncate -s 4294967295 /media/farblos/MCBACKUP/documents/data00.vol
farblos@sappc2:~$ ls -al /media/farblos/MCBACKUP/documents/data00.vol
-rw-r--r-- 1 farblos farblos 4294967295 Dec 17 17:28 /media/farblos/MCBACKUP/documents/data00.vol

farblos@sappc2:~$ udisksctl umount --block-device /dev/sda1
Unmounted /dev/sda1.
farblos@sappc2:~$ udisksctl mount --block-device /dev/sda1
Mounted /dev/sda1 at /media/farblos/MCBACKUP

# Unplug flash drive without further accessing the volume and
# without unmounting, plug it again. Start fsck on the volume.

* What was the outcome of this action?

fsck.vfat insists on not only fixing the dirty bit, but also the large file,
which I have neither read nor written after mounting the flash drive the
second time. Confirmed by hitting this issue at least three times with
different flash drives. Here is the output of the fsck run:

farblos@sappc2:~$ sudo fsck /dev/disk/by-label/MCBACKUP
[sudo] password for farblos:
fsck from util-linux 2.36.1
fsck.fat 4.2 (2021-01-31)
There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
65:01/00
1) Copy original to backup
2) Copy backup to original
3) No action
[123?q]? 2
/documents/data00.vol
File size is 4294967295 bytes, cluster chain length is 0 bytes.
Truncating file to 0 bytes.

*** Filesystem was changed ***
The changes have not yet been written, you can still choose to leave the
filesystem unmodified:
1) Write changes
2) Leave filesystem unchanged
[12?q]? 2
/dev/sda1: 19 files, 1053288/1961982 clusters

* What outcome did you expect instead?

fsck.vfat should fix only the dirty bit and leave any large files alone.

No current issues found, not in upstream Github repo, either. Google
seems to find some similar issues, but they are all older than 10 years.

-- System Information:
Debian Release: 11.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dosfstools depends on:
ii libc6 2.31-13+deb11u2

dosfstools recommends no packages.

dosfstools suggests no packages.

-- no debconf information

[in.cog...@arcor.de]

There is actually a much simpler repro case:

Format volume, create large file, fsck volume, boink:

farblos@sappc2:~$ sudo mkfs.vfat -n MCBACKUP /dev/sdc1
mkfs.fat 4.2 (2021-01-31)
farblos@sappc2:~$ sudo mount /dev/sdc1 /mnt
farblos@sappc2:~$ sudo truncate -s 4294967295 /mnt/bigfile
farblos@sappc2:~$ sudo umount /mnt
farblos@sappc2:~$ sudo fsck.vfat /dev/sdc1
fsck.fat 4.2 (2021-01-31)
/bigfile

File size is 4294967295 bytes, cluster chain length is 0 bytes.
Truncating file to 0 bytes.

*** Filesystem was changed ***
The changes have not yet been written, you can still choose to leave the
filesystem unmodified:
1) Write changes
2) Leave filesystem unchanged
[12?q]? 2

/dev/sdc1: 2 files, 1048577/1961982 clusters