Noticed an interesting tidbit by chance (I, err, mistakenly switched to the "USB Connected" screen while in USBNet mode
):
The (ancient) stock dosfstools used by Kobo appears not to be smart enough to properly identify the dirty bit. Which means it just says "here, that bit was flipped", but it does *not* attempt to fix it.
Which explains why the chain of fsck done during boot never manages to "fix" this.
Broke-ass dosfstools:
Code:
[root@(none) ~]# dosfsck -a -w /dev/mmcblk0p3
dosfsck 3.0.6, 04 Oct 2009, FAT32, LFN
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
65:01/00
Not automatically fixing this.
/dev/mmcblk0p3: 16845 files, 612334/1764440 clusters
Sane dosfstools:
Code:
┌─(ROOT@illyria:pts/1)───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────(~SVN/Bash/trunk)─┐
└─(0.38:52%:20:05:#)── fsck.vfat /dev/sde ──(Tue, Jun 02)─┘
fsck.fat 4.1 (2017-01-24)
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) y
/dev/sde: 16845 files, 612334/1764440 clusters
I'm going to try a current build on-device next, to see if there's an extra sneaky issue somewhere... (I just have to actually trigger the issue in the first place ;D).
(That doesn't change the fact that Nickel should really be more careful when unmounting, so as not to trigger this to begin with, but, at least this would explain why it's never auto-corrected...).
EDIT: Yup, it tracks, dirty bit handling was implemented long after that release:
https://github.com/dosfstools/dosfst...cc9b5f0408bd34