5 replies to this topic

[deomsh]

PBRVIEW.G4B: https://github.com/deomsh/PBRVIEW.G4B

 

PBRVIEW.G4B v0.1 (20231015), by deomsh
Function: display Partition Boot Record on FAT, NTFS or exFAT
PBRVIEW.G4B [--start=N|--skip=n|--force=N] DISK|DEVICE|FILE [/MS|/PQ]
Optional: --start=N|--skip=n|--force=N: N/n is starting sector/byte (0-N/n)
 Use if no partition is given: image-file, disk or blocklist
Optional: /MS|/PQ for Microsoft or PowerQuest style
Remarks:
FILE can be a blocklist too
With --start/--force N sector number is in 512 byte units
 With --start/--skip/--force filesystem derived from jump-code only
 First 4MB is searched for EBxx90 (0x2000 512 byte sectors)
In case of exFAT switch /MS or /PQ changes colors only
Unlock line 26 to change default colors to blue
Example: PBRVIEW.G4B (hd0,0)
Example: PBRVIEW.G4B (fd0) /ms
Example: PBRVIEW.G4B (rd) /pq
Example: PBRVIEW.G4B --start=63 (hd0)
Example: PBRVIEW.G4B (hd0,0)/FATIMAGE.IMG
Example: PBRVIEW.G4B --start=1008 (hd1,0)/IMAGE.IMG
Example: PBRVIEW.G4B --force=1008 (hd1,0)/ISOFILE.ISO
Example: PBRVIEW.G4B --skip=0x3F0 (hd1,0)/FATIMAGE.IMG
Example: PBRVIEW.G4B --start=6 (hd0,0) /ms
Example: PBRVIEW.G4B --skip=0x7E00 (cd)0+0x800
Example: PBRVIEW.G4B (0xe0)0x567+1

History
Version 0.1
First published version

 

There are three styles: Default, Microsoft and PowerQuest. In case of exFAT colors are different only, no official sources from Microsoft found, and PowerQuest is too old for exFAT.

 

Some action print-screens:

 

 

If needed (first) Partition Boot Record is searched in the first 4MB, but only if starting with jump EBxx90. Useful on image-files:

 

 

With switch --start=N (sectors) or --skip=n (bytes) search starts from given offset. For instance to view backup of FAT32 bootsector:

 

 

Also a blocklist can be used. For instance to view Partition Boot Record on an El Torito Bootimage:

 

 

BTW ISOINFO.G4B is not published yet

 

Default color can be changed to blue by unlocking line 26 of the script:

 

 

 

Technical detail: no memory used, al non-textual values are directly read from disk with following sub-routine:
 

:read
#-#+ Function: read 4 bytes in litte endian order from disk and return as hex
#-# Use: call :read ADDRESS FILE
setlocal && set LE= && set result=
raw cat --hex --skip=%~1 --length=4 %~2 | set LE=
set "LE=%LE:~10,11%" &; if not "%LE:~9,1%"==" " && set result=0x%LE:~9,2%%%LE:~6,2%%%LE:~3,2%%%LE:~0,2% ! if not "%LE:~6,1%"==" " && set result=0x%LE:~6,2%%%LE:~3,2%%%LE:~0,2% ! if not "%LE:~3,1%"==" " && set result=0x%LE:~3,2%%%LE:~0,2% ! if not "%LE:~0,1%"==" " && set result=0x%LE:~0,2%
endlocal && set result=%result%
goto :eof

[Wonko the Sane]

As always, good work

 

And  - again as always - I disagree with some of the labels/names you use for some fields (not that it matters), I understand that you followed what the good MS and Powerquest guys did, still some of their labels/names are not good (never were) and some have become obsolete.

 

Namely, at first sight, Using Cnt as suffix (and BS_ or BPB_ prefix) do not add any additional info an steal 3 or 4 characters, "hidden sectors" should (in my perverted mind ) be "Sectors before", and the 55AA is by now almost anywhere called "Magic Bytes".

 

JFYI, when I did something similar (for MBR's) a lot of time ago, I chose my own labels after having checked what the other people did, JFYI:

 

http://jaclaz.alterv...B/USBstick.html

 

Maybe you could add a switch (along with /MS and /PQ) such as /GL (Good Labels)  .

 

Wonko

 

 

[deomsh]

Thanks for taking notice of PBRVIEW.G4B

 

I red your MBR-article a few years ago, but always good to read it again. If you give me a FULL list of FAT/NTFS/exFAT 'Good Labels' I am willing to make you a switch (but will become definite switch /JL ). Max length of each name is 15 characters. But I doubt that is what you ment.

 

Be aware of following considerations: my Default View is my own terminology, reflecting many influences. So open to criticism. I started this project two years ago from a practical need to judge the products from a script I use to make my own FAT12/FAT16/FAT32 images. So for me names are less important than values and offsets.

Up to a few months ago I still used 'magic byte' instead of 'boot signature':

 

 

In using 'magic byte' I followed your script MBRVIEW.G4B. Even my title PBRVIEW.G4B is close, which is practical, because I am using both scripts in conjunction if a MBR is involved. The less I have to change on the grub4dos command-line, the better.

Working with the El Torito specs this summer led me *somehow* to the use of a more descriptive name. So maybe I should abandon 'hidden sectors' too, which seems to have a real meaning in case of the primary partition only. Or am I wrong, are there other reasons to use 'hidden sectors'?

 

The names used with switches /MS and /PQ are NOT my choice, but reflected my need to more easily read-out/ compare while using specs: in case of /MS the 'Microsoft Extensible Firmware Initiative FAT32 File System Specification FAT: General Overview of On-Disk Format'. So all 'BS_' and 'BPB_' prefixes are NOT mine. In case of /PQ I took all names from PTEDIT.EXE to read-out/ compare results in a MS-DOS environment too. So criticism in THESE cases seems pretty useless to me, at least in conjunction with PBRVIEW.G4B

 

If there are more or less 'official' Microsoft names in case of the exFAT Partition Boot Record entries I'de like to know, to enrich switch /MS (as i mentioned in first post now 'colors' is only difference). So far I found forensic sources only.

But it is not a big deal, for now I identify exFAT by parsing the textual output of grub4dos internal command vol - (earlier with EXFAT+spaces  at offset 3), which is enough for my current needs. It is more a 'collectors item'.

[Wonko the Sane]

Any of these names are up to debate, of course.

The Magic Bytes is (IMHO) better than "boot signature" because it really does not mean that it is a signature needed for booting, different OSes/bioses will use it (or ignore it).

 

The Hidden Sectors is instead (pet peeve of mine) a misnamer, those sectors are not in any way "hidden", that field represents the LBA address of the bootsector, thus - unlike the other fields - it is referring to something outside the filesystem, its position on hard disk, "Sectors Before" is so much more descriptive.

Of course all this is only academic/esthetics, anyone that will use this kind of tool should be able to understand the meaning of any field no matter ho they are named.

 

In one of my unfinished batches:

 

https://msfn.org/boa...comment=1001712

 

I have these (for FAT12/FAT16 only):

::§B000_3§Jump_Bytes§H000_03§0§RAW
::§B003_8§OEM_String§S003_08§1§TXT
::§B011_2§Bytes/Sector§N00B_02§2§NUM
::§B013_1§Sectors/Cluster§N00D_01§3§NUM
::§B014_2§Reserved_Sectors§N00E_02§4§NUM
::§B016_1§Number_of_FATs§N010_01§5§NUM
::§B017_2§Max_Root_Entries§N011_02§6§NUM
::§B019_2§Small_Sectors§N013_02§7§NUM
::§B021_1§Media_Type§N015_01§8§NUM
::§B022_2§Sectors/Fat§N016_02§9§NUM
::§B024_2§Sectors/Head§N018_02§10§NUM
::§B026_2§Number_of_Heads§N01A_02§11§NUM
::§B028_4§Sectors_Before§N01C_04§12§NUM
::§B032_4§Large_Sectors§N020_04§13§NUM
::§B036_1§Disk_Number§N024_01§14§NUM
::§B037_1§Current_head§N025_01§15§NUM
::§B038_1§NT_Signature§H026_01§16§NUM
::§B039_4§Volume_Serial§H027_04§17§RAW
::§B043_11§Volume_Label§S02B_0B§18§TXT
::§B054_8§System_ID§S036_08§19§TXT
::§B510_2§Magic_bytes§H1FE_02§20§RAW

Time permiitting, I'll have a look for possible "Good Labels" for FAT32, exFAT and NTFS.

 

 

Wonko

[deomsh]

Nice

 

If you find time to 'do' FAT32 and NTFS, this 'style' will be your reward:

 

 

BTW I use only basic colors, this one was the closest to 'your' blue. Not really close, but not so bad either in my opinion.

 

About exFAT: as I said before, all switches have same entry-names in this case and differ in color only. So exFAT has no priority to 'fill' your switch.

[Wonko the Sane]

I put together something (to be checked/reviewed/verified), from my (old notes).

There are a couple of things on NTFS that need to be looked at/checked/decided upon.

 

From the Structure Viewer built-in in Tiny Hexer, there is an algorithm for Bytes (or Clusters) in $MFT record and Index that may affect the name of the field.

 

Besides, from:

http://ntfs.com/ntfs...boot-sector.htm

there is a "Checksum" field at offset 80(0x50), though I cannot remember having it ever being used (always 0 in my experience).

 

Wonko

Attached Files

•  BSfields.zip   5.27KB   256 downloads

[deomsh]

So far I added your FAT32 entries to your switch.

 

Two problems:

1) I couldn't find a description in your Excel for the field at offset 65/ 0x41 - for now I wrote down 'Unused (1)'

2) Some of your names are too long, I said max 15 chars, gave you already 16 chars. Do you really need so much space?

 

Print screens:

 

 

BTW are you sure about name of field at offset 66/ 0x42?

Why NT_Signature?

Same in case of FAT12/16, offset 38/ 0x26 (see print-screen in my previous post).

 

About NTFS: PBRVIEW.G4B shows the field 'Checksum'. As far I found, this field is not in use (always zero).

 

I would like to know more about how the name of fields $MFT record and Index may be affected.

I saw in your Excel note #1.

 

Scott Mueller gave in Upgrading and Repairing Microsoft® Windows®, Second Edition following comments/ additions:

 

040h 64  BPB_ClusPerMft  1 Clusters per MFT file/folder record. If this number is
                                               positive (00h–7Fh), it represents clusters per MFT
                                               record. If the number is negative (80h–FFh), the size of
                                               the record is 2 raised to the absolute value of this number.

 

044h 68 BPB_ClusPerIndx 1 Clusters per index buffer; it’s used to allocate space for
                                               folders. If this number is positive (00h–7Fh), it represents
                                               clusters per MFT record. If the number is negative
                                               (80h–FFh), the size of the record is 2 raised to the
                                               absolute value of this number.

 

So 'size' should been read as byte-size?

[Wonko the Sane]

Yep, I simply tried to put together my old notes, the sheet is likely to contain some errors/mistakes, and yes, many labels need to be shortened, the 65/0x41 should be "unused" (always zero).

 

The "NT_Signature" is the name given in standard Tiny Hexer Structure viewer for FAT, very likely it is a misnomer and it should be "FAT_signature", see:

http://jdebp.info/FG...fat-widths.html

 

About the two "strange" fields in NTFS, from what I understand if the value is positive, it is expressed in Clusters, if it is negative it is expressed in Bytes.

 

From what I remember, commonly found values are always negative for Bytes/Clusters per $MFT record, i.e. that field comes out always in bytes, whilst the
Bytes/Clusters per Index record is always positive, i.e. that field comes out always in clusters, but evidently it is possible that there are cases where this is not true, hence the Tiny Hexer code that I pasted in notes actually changes the name of the fields depending on the negative or positive values.

 

Wonko

[Wonko the Sane]

16 could be the "right" length, the few longer than 16 could be shortened while remaining understandable at first glance:

 

12345678901234567890   1234567890123456
Filesystem_Version   ->FS_Version
Root_dir_1st_cluster ->RootDir_1st_Clus
Backup_boot_sector   ->Backup_bootsect

Wonko

 

 

[deomsh]

Corrections made, FAT_Signature sounds 'good':

 

 

BTW good source, I studied other pages of Jonathan de Boyne Pollard lately.

 

This time I red his statements about this field more closely. He says the location on 0x26/0x42 (with value 0x28/0x29) is not enough to determine FAT12/16 versus FAT32, because FAT12/16 can be stated in MS-DOS 7.0-boot sector format too (Note 1.).

Although I didn't use this field so far for such purposes, I was a bit alarmed. Are there REAL examples of FAT12/16 boot sectors in a MS-DOS 7.0 fashion, with backup of boot sector etcetera. Or is it just a theoretical possibility?

 

x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x

 

About the two "strange" fields in NTFS:

 

On my NTFS test-vhd's I found following, first print-screen is from a 1GB primary partition, second a small 64MB logical partition:

 

 

BTW numbers seems to be related to 'sectors per cluster'

 

I looked around for more information. I found on http://inform.pucp.e...files/boot.html

an interesting note (c ):

 

 

Maybe helpful?

 

Another thing that bothers me in this respect is the length of the NTFS boot sector entries at 0x40 and 0x44. In my published version I made some corrections, but *somehow* 0x40 is still 4 bytes, like information with note (c ) above. Other sources give 1 byte and 3 bytes reserved/ unused. To me it seems only ONE byte is used, so length should be 1 byte in both cases?

 

BTW in case of NTFS I cheated a bit. I do not show ALL reserved entries, so the view fits on one screen in textmode. 

So NTFS does not have to share the fate of FAT32. 

[Wonko the Sane]

The very good thing about JdeBP is that he writes in a very "strict" manner, I believe that it is a (correct) theoretical issue, absence of evidence doesn't mean evidence of absence, he is (IMHO) saying that a 7.0 BPB FAT 12/16 bootsector is possible, even if he never happened to find one in the wild.

 

The value at 0x40 is 1 byte+3 bytes unused, otherwise the value would not ever become negative, the most common value on NTFS (past a given size) is on 512 bytes/sector devices a cluster size of 8 sectors, and since the $MFT record is (normally) 1024 bytes, the value in there is (again usually) F6 which, in a single byte signed integer corresponds to -10, and like in your posted reference, this means 2^10=0x400=1024 bytes.

Your examples are smallish volumes, where you have 1 or 2  (512 bytes)  sector(s) per cluster, so the $MFT record is represented by number of clusters, but in most cases. the value is actually Bytes (and not Clusters), standard cluster size in the 2GB-2TB is 4096 bytes:

https://support.micr...8f-73169155af95

and I would presume that this range represents the large majority of NTFS volumes.

 

We can derive the conclusion that on 512 bytes/sector if cluster size is bigger than 2 sectors, then the $MFT Record is expressed in bytes, otherwise it is expressed in clusters (but only because I have never seen a $MFT record that is not 1024 bytes in size on these devices, not at all strict).

 

On 4k sectored devices, the $MFT record is always (AFAIK) 4096 bytes in size, so, for small volumes the value is 1 (cluster, as there will be 1 sector per cluster) while in larger volumes (>16TB) it should become again bytes as the cluster size will become 8k.

 

To be honest I never understood fully the use of the size of the $MFT Index (buffer) so I never made any observations about its size, but since it is always bigger than the $MFT Record size, I would (again not strictly) say that it is always expressed in clusters (the case where it will be expressed in bytes should be extremely rare ib some edge cases of manula fomatting/modifying of the NTFS filesystem )

 

Wonko

[deomsh]

Thanks for explanation/ confirmation.

 

I started with NTFS for your switch, truly based on the names in BSfields.xls you provided.

Only two entries are missing, the two you just mentioned. Further I added some 'Unused' names, to align with the other styles.

 

I tested from an USB-drive to view the boot sector of my ±230GB Windows 10 partition. Picture is not soo good:

 

 

As you can see 'value' is negative now on first '???????????????' field at offset 64/ 0x40. I changed the script if the value is 0x80 or above (next field too, but is positive on viewed boot sector).

 

So if you wish you can even provide TWO auto-switching 'good' names, for each of these fields!

 

BTW because I have both 'value' and 'hex' fields, I used the value-field in a broad sense. Some-times little-endian values on disk, sometimes text and sometimes decimal values. Now negative values added.

 

Question: why do you use name 'Sectors/Head' instead of the usual 'Sectors/Track'?

[Wonko the Sane]

"Head" (or "Track")  have actually not any "real" meaning on hard disks made in the last - say - 20 or even 30 years, where there is a "total abstraction" between the physical characteristics of the device, the way actual data/sectors are organized on them and the way the data or sectors are accessed, everything is LBA and goes through (at least) a G-list and a P-list for remapping.

 

Anyway the "other" (obsolete but still relevant in a number of occasions) standard besides LBA is CHS (Cylinder Heads Sectors, we can debate on how they came with this, since it should actually have been CTS Cylinder Track Sectors), so IMHO the "proper" name for this particular abstraction is "Heads", to keep things consistent with what you see in the MBR (of course with GPT the CHS went away, still the Sectors/Head and Number of Heads are needed parts of the geometry in a bootsector)

 

To be exact, the H in CHS stands for Head intended as short for "tracks per cylinder"  

 

I am not sure to understand the reference to 0x80, the border between positive and negative is 0x7F.

The 0xF6 (-10) you found, which as said is in my experience is almost ubiquitous, needs to be translated to 2^abs(-10)=1024

 

The "missing names" could be:

 

Bytes/$MFT record
Clusters/$MFT record

 

and:

 

Bytes/$MFT Index
Clusters/$MFT Index

 

Wonko

[deomsh]

Thanks for elaborating your use of 'Sectors/Head'.

I believe three 'Titans' discussed those nomenclature-issues at length in the past: https://msfn.org/boa...-images/page/5/

I have now an alternative search-phrase too, other results than 'sector/track' I use normally.

 

About negative numbers: I am not so good in their bit/byte representation. I simply took Scott Muellers comment (in my Post #7 above) for granted. Are you sure he is wrong? 0x7F as positive means +127 is the highest 8-bit number, and 0x80 will give -128 as lowest.

 

Your names are fine, today I changed mine already a bit. But they are all longer than 16 chars, one is even 20 chars! If you insist, I will have to give rewrite ALL your lines, to give them more length.

[Wonko the Sane]

Yes, I am sure, the Scott Mueller reference is not talking of 0x80 in the contest of the negative number.

 

0x7F is 127 and it is the maximum number you can express in a signed byte, the method used is 2's complement:

https://en.wikipedia.../2's_complement

and yes, 0x80 is -128.

 

There is an alternative way, called Sign-magnitude:

https://en.wikipedia...#Sign–magnitude

which is more "symmetric" as it allows for 127 max positive and -127 negative, but is not used commonly (AFAIK) and has BTW the drawback that it has two values both meaning 0.  

 

I am not sure to understand, the only three labels longer than 16 I have shortened a few posts above, post #9?

 

The 4 "new" ones, could be shortened as follows?

1234567890123456
Bytes/$MFT_Rec.
Clusts/$MFT_Rec.

Bytes/$MFT_Ind.
Clusts/$MFT_Ind.

BUT- on the other hand - why the 16 character limit at all? It seems to me you have a lot of characters still available in your last screenshot on post #12, re-lenghtening the field to 20 seems possible.

 

You could also rename the header "byte(s)" to "Len." or "Size", gaining 3 characters, after all the actual values in that column are all 1 or 2 characters character in width.

 

If I may (but this is only cosmetics) I would alter the order of columns in the view:

Offset (hex)   Size Description Value (hex)

as it is more similar to what other viewers do and it seems more "natural" to me, answering the questions:

where do I read?

for how long?

what is the meaning?

what is the value?

and in hex?

 

Wonko

[deomsh]

To be sure: this was the content in my post #7 I ment:

 

040h 64  BPB_ClusPerMft  1 Clusters per MFT file/folder record. If this number is
                                               positive (00h–7Fh), it represents clusters per MFT
                                               record. If the number is negative (80h–FFh), the size of
                                               the record is 2 raised to the absolute value of this number.

 

Clearly this is the same meaning of 0x80 as in your first source.

 

About the length of your names: I will give you more space, you have deserved it.    Although this is a lot of work AND a bit tricky, because on some entrances I couldn't simply use '\t', but I had to use 'Fn.4/ Fn.5 calls'. So more testing involved.

My original idea was to have much space as possible at the end of an entry if I wanted to add notes, so with your switch this will not be possible anymore.

 

About your 'cosmetic' suggestion: I am aware of other views, like this one:

 

 

BTW to set/ unset hex-view wouldn't be my choice (and only 'little endian' values showed with hex-view!) . Also watch the strange suggestion the 'JMP instruction' could be wrong in case of FAT32 (maybe because >32 MB?). This suggestion can be exFAT only (as far as I could find).

 

Personally I am 'meaning oriented'. I like most to get the entry-name first, next the value (that's why this can be a 'mixed' field). Only in case of 'Media_Type', 'Disk_Number' and 'FAT_signature' reading the hex-value first would be better.

 

The other columns are useful after deciding to check the boot sector with 'cat --hex', writing a new value or comparing with other sources. Greyed-out offset's first would be acceptable, but not decimal an hex both.

[Wonko the Sane]

Oops, my bad, I thought you were referring to the image in your post #10. 

 

But we are saying the same thing.

0x7F is the last possible positive value, corresponding to the highest possible number, 127

0x80 is the first value representing a negative value that - because of the "inverted" order corresponds to -128, i.e.the lowest possible number.

 

When I said that the border is at 0x7F I meant that anything bigger than 0x7F is negative.

 

The order of columns is not at all important, if it is too much work or if changing it would mean reducing possible future additions, forget about it.

 

As well, if 16 is good for you, let's leave it "as is" and use the shorter labels.

 

Wonko

 

 

[deomsh]

Good

 

I tried to implement your last four long names, but it is a disaster: almost all horizontal '\t'-tabs are 'destroyed'. So I will stick to your shorter names.

 

-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x

 

One question left about your use of the name 'Current_Head' in case of the FAT-boot sectors. Can you explain?

I found a Microsoft document about this already: https://jeffpar.gith...kb/140/Q140418/

[Wonko the Sane]

Hmmm.

 

Good question.

 

From the source you found (the good MS guys of 20+ years ago, not that they were any better than the current MS guys at explaining/documenting things):

 

 

Current Head: This is another field typically used when doing INT13 BIOS calls.
The value would originally have been used to store the track on which the boot
record was located, but the value stored on disk is not currently used as such.
Therefore, Windows NT uses this field to store two flags:

- The low order bit is a "dirty" flag, used to indicate that autochk should run
chkdsk against the volume at boot time.

- The second lowest bit is a flag indicating that a surface scan should also be
run.

 

I will gladly translate it in plain English:

The name derives from something that we don't use anymore since DOS 1.0 or 2.0 (or something like that), we kept it as is because:

1) for historical reasons
2) because we are too §@ç#ing lazy to change it, let alone documenting the changes

Now, we are publishing how in the (meantime  obsolete) NT versions like 3.1 and 3.5) we misused it to meaning "dirty filesystem, needs autocheck"  or "really dirty filesystem, needs a surface scan".

To simplify the explanation we don't actually say that this value is normally 0, but that it can become 1, 2 to mean the first or the second, or 3 for both[2], we instead babble about low order bit and second lowest bit.[1]

When we updated this article in 2001 (well before removing it, but well after FAT32 became in use) we forgot to say that also FAT32 has a similar field which may (or may not) be used on the same way by some NT versions, that we prefer to call "BS_Reserved1" and that we describe as: 

 

"This field has the same definition as it does for FAT12 and FAT16
media. The only difference for FAT32 media is that the field is at a
different offset in the boot sector."

 

Also. we will call from now on these two bits "Dirty Bit" (singular) without ever saying where it (they) can be found, particularly on NTFS where we moved it (they) into the $MFT.

 

 

And now, for no apparent reason, let's talk dirty:
http://reboot.pro/in...showtopic=18030

 

Now, seriously, we can choose among:

Current_Head <-historical

Dirty_FS_Flag <-possibly accurate

Reserved <-generic

 

The reason why I kept "Current_head" in FAT16 (offset 37) and "forgot" it in FAT32 (offset 65) is obviously because I was as well too §@ç#ing lazy to change the name, let alone documenting it. 

 

Wonko

 

 

[1] the explanation here is somehow more undestandable:

 

https://www.win.tue..../fat/fat-1.html

 

(FAT 16)
37 Reserved (Earlier: Current Head, the track containing the Boot Record)
        Used by Windows NT: bit 0: need disk check; bit 1: need surface scan

(FAT32)

65      Reserved - used to be Current Head (used by Windows NT)

 

[2] though values of 2 or 3 have never been observed in the wild, only 0 (normal/clean) and 1 (dirty)

[deomsh]

I agree: it's a bit of a 'dark' story.

 

PowerQuest's PTEDIT used 'Dirty Flag', I used 'reserved NT' and the note I added two days ago says 'flags in win NT'

 

Earlier I found some file-systems set Dirty_Bit if mounting USB-volumes and set back to zero after unmounting. If not set back to zero this seems to give problems in Windows 10 too. There are many stories to find about.

 

My tool FATINFO.G4B (in test-mode) checks the Dirty Bit for this purpose (at 0x25 or 0x41), but reports in case (USB-)floppies only. Maybe I should add (USB-)hard disks too.

 

I am curious which 'good name' you will choose for the 0x25 AND the 0x41 case.

 

 

 

 

[Wonko the Sane]

I don't know if it is "Dirty_FS_Flag" only in NT systems , maybe it is used in the same way on some DOS and win 9x/ME?

 

In any case, either it is "unused" on some Operating Systems or, when it is used, it seems to be used only as "Dirty_FS_Flag" and - likely - its only two actually used values for the whole byte seem to be 0=clean and 1=dirty.

 

Surely noone ever will be running one of the early OSes where it actually meant "Current_Head" and use on the same volume grub4dos, and the 0.000000000000000000001 % that might, as they are on this kind of retro-computing hobby will likely know about the use of that bit/byte, so my personal vote today goes to "Dirty_FS_Flag".

 

Wonko

[deomsh]

I never found any evidence Win9x is using your 'Dirty_FS_Flag'. To be sure I tested today, but nothing happened.

As far as I know Win9x is using the Shutdown flag in the start of the File Allocation Table. The status is read-out in test-mode of FATINFO.G4B (except on FAT12):

 

 

About old DOS-versions: so far only Partition/Volume Boot Record Version 4.0 and Version 7.0 are supported in PBRVIEW.G4B. If anyone needs older versions: just ask, BUT in that case the testing must be done by the questioner.

 

I believe the 'Dirty Flag' in the boot sector is still relevant today if FAT is used by Windows NTx. I just 'healed' my FAT32 USB Pen-drive with both USB-A and micro-USB connections carrying the 'Dirty Bit' at 0x41. Probably caused by 'bad' unmounting on my Android smarthone. Windows 10 asked for month's 'running' CHKDISK - never found OR solved anything. Now everything is fine (for the time being...).

 

To help you to make up your mind, two print-screens with your latest 'Good' names:

 

 

BTW in case of PowerQuest-names: 'Dirty Flag' is used on FAT12/FAT16 only. On FAT32 it should be 'Reserved for NT'.

[Wonko the Sane]

 

BTW in case of PowerQuest-names: 'Dirty Flag' is used on FAT12/FAT16 only. On FAT32 it should be 'Reserved for NT'.

 

Personally I would go "all in", if (according to the good MS guys) the field is the same, only at a different offset, it should have the same name everywhere, "Dirty_FS_Flag".

 

Wonko

[deomsh]

All right, I will stick to "Dirty_FS_Flag" for your switch: FAT and NTFS are 'done'.

About exFAT, lately I landed on a Microsoft source, searching something else: https://learn.micros.../filex/chapter3
I decided to change all exFAT names in PBRVIEW.G4B according to the Azure RTOS FileX documentation. Almost all are the same names as earlier (found in Forensic sources), only spaces between.

This time I added the 'Reserved' field on offset 11/ 0xB (in v0.1 only checked for the 53 zeros, not showed). Also alignment of last three column's in the Default view has been slightly changed, which affects exFAT for all switches.

Maybe value-translation for field 'File System' revision should be 01:00 instead of the dumb '256' now?

As I said before, all switches have have same names now, differ in color only. In case of your's:



Do you 'like' (or 'not dislike') this choice, or do you want to give your own 'Good' exFAT names?

Another possibility is your switch will NOT work with exFAT, displaying some nice 'echo' accordingly.

[Wonko the Sane]

Semi-random question:

Where (the heck) is gone the 16 characters length limitation?

 

"First cluster of root directory" is acceptable in exFAT

1234567890123456789012345678901
First cluster of root directory

 but "Clusters/$MFT record"

12345678901234567890
Clusters/$MFT record

needs to be shortened to "Clusts/$MFT_Rec.":

1234567890123456
Clusts/$MFT_Rec.

to fit in 16 characters in NTFS?

 

Whatever, no prob.

 

The names you used for exFAT are just fine, they are understandable (though long ) and in practice corresponding to those in:

https://www.ntfs.com...boot-sector.htm

 

Yep, the 256 makes little sense, 01.00 would be more accurate.

 

Wonko.