No, Ddan was right.
I now 'fixup' INDX structures too and it has 'fixed' a few issues, such as incomprehensibly corrupted filenames etc.
PS. I'm not getting emails anymore when sombody posts in these threads. Is this just me or is there a site malfunction ?
Sorry for not replying sooner.
As far as I am aware fixup is used in mft records, indx records and logfile records. Whichever set you are processing, fixup needs to be done on that set. As you have noted, not doing fixup can cause all sorts of bizarre issues.
With the count of fixup words, since fixup is done on a sector by sector basis, you need one word for each sector in the record plus one control word.
Ddan
Sorry for not replying sooner.
As far as I am aware fixup is used in mft records, indx records and logfile records. Whichever set you are processing, fixup needs to be done on that set. As you have noted, not doing fixup can cause all sorts of bizarre issues.
With the count of fixup words, since fixup is done on a sector by sector basis, you need one word for each sector in the record plus one control word.
Ddan
Thanks Ddan
Anyone knows what the 4 byte signature is for, that is found right after the record end marker (0xFFFFFFFF)?
It signals the end of the record. You can regard it as an attribute that contains nothing and is called END.
Ddan
Yes I know that the 0xFFFFFFF is the END, but are you saying that the 4 bytes after it is just a definite end (a second confirmation of record end)? It just seems strange..
Sorry misunderstood your question.
If you are talking about anything after the the four 0xFF bytes, this is just rubbish in the slack space. If you see a second set of these four bytes it basically means that the record was longer at some stage. You may even see more sets. If you have, for example along filename, this will also produce a dos name. The process of working out the dos name causes the record length to shrink. I think it starts out with two long filenames and then changes the first entry to a dos name. You can often see this as part of the dos name attribute.
Ddan
It can't be rubbish as it's the same 4 bytes all over. I have not done thorough tests, but just felt like asking based on past experience and what (from my memory) appears to be a consistent find.. Ie, the 4 bytes are there on volumes created on different systems.
Read my earlier explanation using long filenames as an example. The same process would apply to the same file wherever it was, so I would expect the bytes in the slack space immediately after the end to always be the same.
If you can find an mft record which has an attributelist (0x20) attribute, have a look at that in detail. Before the 0x20 was created the record must have been almost full. You can often see complete attributes in the slack space of these records. You can also trace that these attributes are now in the 0x20.
Ddan