lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <5718D0F8.5090502@bitwise.fi>
Date:	Thu, 21 Apr 2016 16:09:12 +0300
From:	Anssi Hannula <anssi.hannula@...wise.fi>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	linux-fsdevel@...r.kernel.org
Cc:	Oleksij Rempel <bug-track@...her-privat.net>,
	linux-kernel@...r.kernel.org
Subject: fat: changed filesystem dirty bit behavior

Hi all!

Starting with commit b88a105802e9aeb [1] ("fat: mark fs as dirty on
mount and clean on umount") FAT(32) filesystems are now marked as
"dirty" on mount and clean on unmount.

The commit message says that this is similar to Win 7 behavior - "Win 7,
set dirty flag on first write and remove it on umount".
However, I have been unable to coerce my Windows 7 system to set this
flag on a FAT32 filesystem, when tested both with portable (USB) and
fixed disks. Have they maybe changed this with an update, or does
someone else still see this bit set on Win7 or later?

This change is a bit problematic on a legacy embedded application I'm
working on, as the user interface doesn't have any separate
eject/unmount button for a USB stick - it relies on the user not
unplugging the stick while a data transfer is in progress.
So, when the system is upgraded to a modern vanilla kernel version, this
bit is set when the USB stick is unplugged, causing Windows to always
prompt whether to scan and fix the drive, which is annoying/confusing
for users.

Would a patch to add a filesystem option to restore the previous (and
seemingly Win7) behavior be accepted?

Or is this a case where the application is just considered to be broken?
(as setting the dirty bit seems technically correct, even if Windows
doesn't do it)

Or anything else I'm missing?

For reference, on FAT32 this is bit 0 of byte 0x41 (61) of the first sector.

[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b88a105802e9aeb6e234e8106659f5d1271081bb

-- 
Anssi Hannula / Bitwise Oy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ