I know, I know, it does seem - besides queerly titled - "out of place".
It is not, rest assured.
Let's call it a "spin-off" from this thread/posts:
http://reboot.pro/to...ting-to-isosel/
http://reboot.pro/to...sosel/?p=165006
Where (the HECK) is the "dirty bit"?
Is it a bit or a byte?
From the mouth of the wolf:
http://support.micro...kb/322275/en-us
The "dirty" bit is a bit in the boot sector (for FAT or FAT32 volumes), or in the MFT (for NTFS volumes), that is checked when Windows starts. This bit is checked to determine whether corruption has been detected in the file system. If the dirty bit is set on a volume, Autochk runs to correct any errors on the volume.
I strongly suspect that - as always - MS info is either misleading or wrong (or BOTH).
Here:
http://www.raymond.c...without-chkdsk/
the "bit" (that in the meantime has misteriously grown to a WHOLE byte ) is clear enough for NTFS (the actual filesystem we are NOT interested in for matters related to ISOSEL/Isostick)
It is far less clear (and I suspect outright wrong ) for FAT32 (whilst FAT16 is not analyzed at all).
Anyway the identified byte (not bit), confusingly said as being "41" without specifiying if it is hex or dec offset in the bootsector, may correspond BOTH if hex or if dec (i.e. hex 29) to reserved bytes/part of reserved word according to the ONLY source I do actually trust, the Starman's pages:
http://thestarman.na...mbr/MSWIN41.htm
Quite surprisingly some apparently more reasonable info can be gathered by reading some Apple source code:
http://www.opensourc...dos.tproj/fat.c
/* * Determine whether a volume is dirty, without reading the entire FAT. */ int isdirty(int fs, struct bootblock *boot, int fat) { int result; u_char *buffer; off_t offset; result = 1; /* In case of error, assume volume was dirty */ /* FAT12 volumes don't have a "clean" bit, so always assume they are dirty */ if (boot->ClustMask == CLUST12_MASK) return 1; buffer = malloc(boot->BytesPerSec); if (buffer == NULL) { perr("No space for FAT sector"); return 1; /* Assume it was dirty */ } offset = boot->ResSectors + fat * boot->FATsecs; offset *= boot->BytesPerSec; if (lseek(fs, offset, SEEK_SET) != offset) { perr("Unable to read FAT"); goto ERROR; } if (deblock_read(fs, buffer, boot->BytesPerSec) != boot->BytesPerSec) { perr("Unable to read FAT"); goto ERROR; } switch (boot->ClustMask) { case CLUST32_MASK: /* FAT32 uses bit 27 of FAT[1] */ if ((buffer[7] & 0x08) != 0) result = 0; /* It's clean */ break; case CLUST16_MASK: /* FAT16 uses bit 15 of FAT[1] */ if ((buffer[3] & 0x80) != 0) result = 0; /* It's clean */ break; }
and
/* * Check the second (index 1) entry of the FAT. It should be set to an * end of file mark. For FAT16 and FAT32, the upper two bits may be cleared * to indicate "volume dirty" and "hard errors"; for FAT12, it must always * be an EOF value. * * Also check the "clean" bit. If it is not set (i.e., the volume is dirty), * set the FSDIRTY status. */ value = fat_get(1); if (value == CLUST_ERROR) return FSFATAL; switch (boot->ClustMask) { case CLUST16_MASK: if ((value & 0x8000) == 0) mod |= FSDIRTY; break; case CLUST32_MASK: if ((value & 0x08000000) == 0) mod |= FSDIRTY; break; default: break; } /* * Figure out how many bits of the FAT[1] entry to compare. FAT16 and * FAT32 use the upper two bits as flags, so we don't want to compare * them. The >>2 part below leaves temp set to the cluster mask, but * with the upper two bits zeroed. (Note that the cluster mask has * the lower N bits set.) FAT12 has no flags, and uses all 12 bits. *
Please note how the byte has suddenly reverted to a smaller bit BUT moved from the bootsector to the FAT.
Additionally it seems like TWO bits are involved
It would be much appreciated if some of the peeps with more C reading capabilities than myself could check the above source code and possibly also check the corresponding Freedos and Linux ones.
The "good" MS originated reference for FAT is if course NOT the half-@§§ed above mentioned KB but this document:
http://staff.washing...c/fatgen103.pdf
which actually (page 18) does re-establish:
For FAT16 and
FAT32, the file system driver may use the high two bits of the FAT[1] entry for dirty volume flags (all
other bits, are always left set to 1). Note that the bit location is different for FAT16 and FAT32,
because they are the high 2 bits of the entry.
For FAT16:
ClnShutBitMask = 0x8000;
HrdErrBitMask = 0x4000;
For FAT32:
ClnShutBitMask = 0x08000000;
HrdErrBitMask = 0x04000000;
Bit ClnShutBitMask– If bit is 1, volume is “clean”.
If bit is 0, volume is “dirty”. This indicates that the file system driver did not
Dismount the volume properly the last time it had the volume mounted. It
would be a good idea to run a Chkdsk/Scandisk disk repair utility on it,
because it may be damaged.
Bit HrdErrBitMask– If this bit is 1, no disk read/write errors were encountered.
If this bit is 0, the file system driver encountered a disk I/O error on the
Volume the last time it was mounted, which is an indicator that some sectors
may have gone bad on the volume. It would be a good idea to run a
Chkdsk/Scandisk disk repair utility that does surface analysis on it to look
for new bad sectors.
that the bits are TWO and that they are NOT in the bootsector at all, but rather at the beginning of the FAT.
What is not (yet and to me) clear at all is how the second copy of the FAT is affected, and what happens when just one of the two copies have that bit changed.
Another question is now (reserved to ElegantInvention) WHICH of the two bits (or both) does ISOSEL check? Only the "first one", i.e. the "real" volume dirty one? Or both?
And another one (opened to everyone, but particularly aimed at bblaauw that originally had the idea to run a DOS to change ISO_FILENAME.TXT AND owns an actual Isostick AND usually knows where his towel is ):
How about testing the same ISO_FILENAME.TXT writing in grub4dos? (and if needed settign the stupid bit(s) programmatically from grub4dos)
Wonko