Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751751AbcDUNQe (ORCPT ); Thu, 21 Apr 2016 09:16:34 -0400 Received: from mail.bitwise.fi ([109.204.228.163]:35156 "EHLO mail.bitwise.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751172AbcDUNQd (ORCPT ); Thu, 21 Apr 2016 09:16:33 -0400 X-Greylist: delayed 431 seconds by postgrey-1.27 at vger.kernel.org; Thu, 21 Apr 2016 09:16:32 EDT From: Anssi Hannula Subject: fat: changed filesystem dirty bit behavior Cc: Oleksij Rempel , linux-kernel@vger.kernel.org To: OGAWA Hirofumi , linux-fsdevel@vger.kernel.org Message-ID: <5718D0F8.5090502@bitwise.fi> Date: Thu, 21 Apr 2016 16:09:12 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1579 Lines: 38 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