How to 'Manually' clear the FAT32 'dirty' bit?












2















As per the Microsoft FAT32 'specification', FAT32 volumes should have their 'clean' flag (ClnShutBit) cleared when mounted and set when unmounted/ejected.



Indeed, this is the behaviour on Linux & Mac OS X - mounting a FAT32 USB device read/write marks it as 'dirty' and unmounting it marks it 'clean'. If the device is removed without unmounting/ejecting, the flag remains cleared (not clean / dirty).



If a USB drive flagged 'dirty' is inserted into Windows 10, it pops-up a message for the user saying "There might be a problem..." and prompting for a Scan & Fix. This is technically true - there 'might' be a problem, but also might not (e.g. if writes to the drive were fully flushed prior to manual removal).
Windows doesn't stick to the 'spec' - it appears to mark USB drives clean even while mounted so that they don't get this prompt if they're manually removed and re-inserted (perhaps it flags dirty prior to write operations and clean after completion? - I don't know).



How can I force this flag to be clean on Linux?



(please, no answers about why not to do it etc.)



The Wikipedia FAT Filesystem design entry talks about Special entries in a FAT and there is a Microsoft document floating around the InterWebs named "Microsoft FAT Specification" (FAT32 Spec (SDA Contribution).pdf) that talks about the ClnShutBitMask.



However, I'm unclear how to find it. If I mount a USB FAT32 volume (on Linux) as read-only, copy the content to a file using dd, then re-mount it as read-write and copy it again, the bytes are the same.



e.g. 8GB USB drive df reports as on /dev/sdd1



sudo mount -o remount,ro /media/user/USB/
sudo dd if=/dev/sdd of=/tmp/usbbytes-ro bs=1024 count=8388608
sudo mount -o remount,rw /media/user/USB/
sudo dd if=/dev/sdd of=/tmp/usbbytes-rw bs=1024 count=8388608
cmp -l /tmp/usbbytes-ro /tmp/usbbytes-rw


Reports nothing different.
FYI:



sudo file -s /dev/sdd   
/dev/sdd: DOS/MBR boot sector; partition 1 : ID=0xc, active, start-CHS (0x0,32,33), end-CHS (0x3d3,48,29), startsector 2048, 15728640 sectors
sudo file -s /dev/sdd1
/dev/sdd1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "SYSLINUX", sectors/cluster 8, Media descriptor 0xf8, sectors/track 62, heads 248, hidden sectors 2048, sectors 15728640 (volumes > 32 MB), FAT (32 bit), sectors/FAT 15336, reserved 0x1, serial number 0x98d03da8, label: "USB "


Any ideas?



(for the curious, we have an embedded device running Debian9 which allows users to insert and manually remove USB drives, but has no UI facility for 'ejecting'. Users complain that any USB inserted and removed from the device subsequently gives the 'scan & fix' prompt on Windows)



Thanks!










share|improve this question























  • Some info here....github.com/dosfstools/dosfstools/issues/38

    – Moab
    Jan 24 at 23:47











  • Also here....thestarman.pcministry.com/DOS/DirtyShutdownFlag.html

    – Moab
    Jan 24 at 23:48











  • Similar question on Unix & Linux SE.

    – Kamil Maciorowski
    Jan 24 at 23:57
















2















As per the Microsoft FAT32 'specification', FAT32 volumes should have their 'clean' flag (ClnShutBit) cleared when mounted and set when unmounted/ejected.



Indeed, this is the behaviour on Linux & Mac OS X - mounting a FAT32 USB device read/write marks it as 'dirty' and unmounting it marks it 'clean'. If the device is removed without unmounting/ejecting, the flag remains cleared (not clean / dirty).



If a USB drive flagged 'dirty' is inserted into Windows 10, it pops-up a message for the user saying "There might be a problem..." and prompting for a Scan & Fix. This is technically true - there 'might' be a problem, but also might not (e.g. if writes to the drive were fully flushed prior to manual removal).
Windows doesn't stick to the 'spec' - it appears to mark USB drives clean even while mounted so that they don't get this prompt if they're manually removed and re-inserted (perhaps it flags dirty prior to write operations and clean after completion? - I don't know).



How can I force this flag to be clean on Linux?



(please, no answers about why not to do it etc.)



The Wikipedia FAT Filesystem design entry talks about Special entries in a FAT and there is a Microsoft document floating around the InterWebs named "Microsoft FAT Specification" (FAT32 Spec (SDA Contribution).pdf) that talks about the ClnShutBitMask.



However, I'm unclear how to find it. If I mount a USB FAT32 volume (on Linux) as read-only, copy the content to a file using dd, then re-mount it as read-write and copy it again, the bytes are the same.



e.g. 8GB USB drive df reports as on /dev/sdd1



sudo mount -o remount,ro /media/user/USB/
sudo dd if=/dev/sdd of=/tmp/usbbytes-ro bs=1024 count=8388608
sudo mount -o remount,rw /media/user/USB/
sudo dd if=/dev/sdd of=/tmp/usbbytes-rw bs=1024 count=8388608
cmp -l /tmp/usbbytes-ro /tmp/usbbytes-rw


Reports nothing different.
FYI:



sudo file -s /dev/sdd   
/dev/sdd: DOS/MBR boot sector; partition 1 : ID=0xc, active, start-CHS (0x0,32,33), end-CHS (0x3d3,48,29), startsector 2048, 15728640 sectors
sudo file -s /dev/sdd1
/dev/sdd1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "SYSLINUX", sectors/cluster 8, Media descriptor 0xf8, sectors/track 62, heads 248, hidden sectors 2048, sectors 15728640 (volumes > 32 MB), FAT (32 bit), sectors/FAT 15336, reserved 0x1, serial number 0x98d03da8, label: "USB "


Any ideas?



(for the curious, we have an embedded device running Debian9 which allows users to insert and manually remove USB drives, but has no UI facility for 'ejecting'. Users complain that any USB inserted and removed from the device subsequently gives the 'scan & fix' prompt on Windows)



Thanks!










share|improve this question























  • Some info here....github.com/dosfstools/dosfstools/issues/38

    – Moab
    Jan 24 at 23:47











  • Also here....thestarman.pcministry.com/DOS/DirtyShutdownFlag.html

    – Moab
    Jan 24 at 23:48











  • Similar question on Unix & Linux SE.

    – Kamil Maciorowski
    Jan 24 at 23:57














2












2








2








As per the Microsoft FAT32 'specification', FAT32 volumes should have their 'clean' flag (ClnShutBit) cleared when mounted and set when unmounted/ejected.



Indeed, this is the behaviour on Linux & Mac OS X - mounting a FAT32 USB device read/write marks it as 'dirty' and unmounting it marks it 'clean'. If the device is removed without unmounting/ejecting, the flag remains cleared (not clean / dirty).



If a USB drive flagged 'dirty' is inserted into Windows 10, it pops-up a message for the user saying "There might be a problem..." and prompting for a Scan & Fix. This is technically true - there 'might' be a problem, but also might not (e.g. if writes to the drive were fully flushed prior to manual removal).
Windows doesn't stick to the 'spec' - it appears to mark USB drives clean even while mounted so that they don't get this prompt if they're manually removed and re-inserted (perhaps it flags dirty prior to write operations and clean after completion? - I don't know).



How can I force this flag to be clean on Linux?



(please, no answers about why not to do it etc.)



The Wikipedia FAT Filesystem design entry talks about Special entries in a FAT and there is a Microsoft document floating around the InterWebs named "Microsoft FAT Specification" (FAT32 Spec (SDA Contribution).pdf) that talks about the ClnShutBitMask.



However, I'm unclear how to find it. If I mount a USB FAT32 volume (on Linux) as read-only, copy the content to a file using dd, then re-mount it as read-write and copy it again, the bytes are the same.



e.g. 8GB USB drive df reports as on /dev/sdd1



sudo mount -o remount,ro /media/user/USB/
sudo dd if=/dev/sdd of=/tmp/usbbytes-ro bs=1024 count=8388608
sudo mount -o remount,rw /media/user/USB/
sudo dd if=/dev/sdd of=/tmp/usbbytes-rw bs=1024 count=8388608
cmp -l /tmp/usbbytes-ro /tmp/usbbytes-rw


Reports nothing different.
FYI:



sudo file -s /dev/sdd   
/dev/sdd: DOS/MBR boot sector; partition 1 : ID=0xc, active, start-CHS (0x0,32,33), end-CHS (0x3d3,48,29), startsector 2048, 15728640 sectors
sudo file -s /dev/sdd1
/dev/sdd1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "SYSLINUX", sectors/cluster 8, Media descriptor 0xf8, sectors/track 62, heads 248, hidden sectors 2048, sectors 15728640 (volumes > 32 MB), FAT (32 bit), sectors/FAT 15336, reserved 0x1, serial number 0x98d03da8, label: "USB "


Any ideas?



(for the curious, we have an embedded device running Debian9 which allows users to insert and manually remove USB drives, but has no UI facility for 'ejecting'. Users complain that any USB inserted and removed from the device subsequently gives the 'scan & fix' prompt on Windows)



Thanks!










share|improve this question














As per the Microsoft FAT32 'specification', FAT32 volumes should have their 'clean' flag (ClnShutBit) cleared when mounted and set when unmounted/ejected.



Indeed, this is the behaviour on Linux & Mac OS X - mounting a FAT32 USB device read/write marks it as 'dirty' and unmounting it marks it 'clean'. If the device is removed without unmounting/ejecting, the flag remains cleared (not clean / dirty).



If a USB drive flagged 'dirty' is inserted into Windows 10, it pops-up a message for the user saying "There might be a problem..." and prompting for a Scan & Fix. This is technically true - there 'might' be a problem, but also might not (e.g. if writes to the drive were fully flushed prior to manual removal).
Windows doesn't stick to the 'spec' - it appears to mark USB drives clean even while mounted so that they don't get this prompt if they're manually removed and re-inserted (perhaps it flags dirty prior to write operations and clean after completion? - I don't know).



How can I force this flag to be clean on Linux?



(please, no answers about why not to do it etc.)



The Wikipedia FAT Filesystem design entry talks about Special entries in a FAT and there is a Microsoft document floating around the InterWebs named "Microsoft FAT Specification" (FAT32 Spec (SDA Contribution).pdf) that talks about the ClnShutBitMask.



However, I'm unclear how to find it. If I mount a USB FAT32 volume (on Linux) as read-only, copy the content to a file using dd, then re-mount it as read-write and copy it again, the bytes are the same.



e.g. 8GB USB drive df reports as on /dev/sdd1



sudo mount -o remount,ro /media/user/USB/
sudo dd if=/dev/sdd of=/tmp/usbbytes-ro bs=1024 count=8388608
sudo mount -o remount,rw /media/user/USB/
sudo dd if=/dev/sdd of=/tmp/usbbytes-rw bs=1024 count=8388608
cmp -l /tmp/usbbytes-ro /tmp/usbbytes-rw


Reports nothing different.
FYI:



sudo file -s /dev/sdd   
/dev/sdd: DOS/MBR boot sector; partition 1 : ID=0xc, active, start-CHS (0x0,32,33), end-CHS (0x3d3,48,29), startsector 2048, 15728640 sectors
sudo file -s /dev/sdd1
/dev/sdd1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "SYSLINUX", sectors/cluster 8, Media descriptor 0xf8, sectors/track 62, heads 248, hidden sectors 2048, sectors 15728640 (volumes > 32 MB), FAT (32 bit), sectors/FAT 15336, reserved 0x1, serial number 0x98d03da8, label: "USB "


Any ideas?



(for the curious, we have an embedded device running Debian9 which allows users to insert and manually remove USB drives, but has no UI facility for 'ejecting'. Users complain that any USB inserted and removed from the device subsequently gives the 'scan & fix' prompt on Windows)



Thanks!







linux filesystems fat32






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Jan 24 at 22:45









DavidJDavidJ

11314




11314













  • Some info here....github.com/dosfstools/dosfstools/issues/38

    – Moab
    Jan 24 at 23:47











  • Also here....thestarman.pcministry.com/DOS/DirtyShutdownFlag.html

    – Moab
    Jan 24 at 23:48











  • Similar question on Unix & Linux SE.

    – Kamil Maciorowski
    Jan 24 at 23:57



















  • Some info here....github.com/dosfstools/dosfstools/issues/38

    – Moab
    Jan 24 at 23:47











  • Also here....thestarman.pcministry.com/DOS/DirtyShutdownFlag.html

    – Moab
    Jan 24 at 23:48











  • Similar question on Unix & Linux SE.

    – Kamil Maciorowski
    Jan 24 at 23:57

















Some info here....github.com/dosfstools/dosfstools/issues/38

– Moab
Jan 24 at 23:47





Some info here....github.com/dosfstools/dosfstools/issues/38

– Moab
Jan 24 at 23:47













Also here....thestarman.pcministry.com/DOS/DirtyShutdownFlag.html

– Moab
Jan 24 at 23:48





Also here....thestarman.pcministry.com/DOS/DirtyShutdownFlag.html

– Moab
Jan 24 at 23:48













Similar question on Unix & Linux SE.

– Kamil Maciorowski
Jan 24 at 23:57





Similar question on Unix & Linux SE.

– Kamil Maciorowski
Jan 24 at 23:57










0






active

oldest

votes











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1398115%2fhow-to-manually-clear-the-fat32-dirty-bit%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























0






active

oldest

votes








0






active

oldest

votes









active

oldest

votes






active

oldest

votes
















draft saved

draft discarded




















































Thanks for contributing an answer to Super User!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1398115%2fhow-to-manually-clear-the-fat32-dirty-bit%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Plaza Victoria

Puebla de Zaragoza

Musa