NTFS ins and outs

However, when the attributes are bigger still and a resident 0x20 will not fit, the list is made non-residen
Ddan

I did not know that (and have not seen it happen on my system either). Another thing to implement then.

Still, that's not what I meant actually.

Consider the attributes list (0x20), resident or not, is present and points to several MFT records.

I thought that a single attribute, any attribute, was always limited to one MFT record of the list of MFT records for a file.

Yet I found that when a file has many extents, and a DATA attribute (0x80) has so much data that it cannot fit in one MFT record, that it also spans several MFT records !! So not not-resident, but resident, yet present in more than one MFT records for that file.

I hope it makes sense ?
Have you tried compressing a large text file ?
The x+y=16 clusters compression mechanism will create many runs for the file. This way I can easily repeat this.

I understand what you are saying now, basically it turned out not quite as you expected. I've found the file system to be like that, just when you think you have everything straight, it throws another curved one at you!

Have you tried compressing a large text file ?
The x+y=16 clusters compression mechanism will create many runs for the file. This way I can easily repeat this.

I don't really need to do this as I have many examples of both resident and non-resident 0x20 attributes. Googling for info on this subject seems to suggest that their occurrence is rare but my experience is that it isn't, at least as far as resident lists are concerned.

Ddan

I have released a new Beta version www.isobuster.com/beta/

I've tried this against the same image as the earlier release and the two problems noted before have been fixed. There does seem to be a new problem connected with the 0x20 attribute.

The image had two such files on and one extracted ok, the other didn't. The file that did extract ok had a single 0x80 data attribute in the list. The one that failed had two 0x80 attributes in the list. It extracted to a zero length file instead of 14.5mb and I noted that its lba value was incorrect.

Ddan

Thanks Ddan,

Strange because this is exactly something that was (supposed to be) fixed !?

I'll look into it and will alert you of the next beta, probably tomorrow.

Hi,

I released another beta today. A bit later than expected.
www.isobuster.com/beta/

I looked into the issue you reported Ddan, but could not see it. Can you re-test because some things have changed in the code wrt this functionality.

Cheers.

The problem reported earlier seems to have gone away. The beta now finds the correct lba and extracts properly.

I've come across one other problem and an anomaly.

The problem relates to files having dual extent data runs, ie 31 01 29 E5 01 21 01 BE 0A 00 for example (all in hex). It seems that the beta is reading the cluster after the first for the remainder of the file data instead of the second cluster at the given offset. In this example clusters 0x1E529 and 0x1E52A instead of 0x1E529 and 0x01EFE7.

The anomaly is a real headache. I'm trying to find a base to compare recovered files against. I have a WinHex raw disk image (type .001) and have selected a folder that I know shows some discrepancies. If I extract the folder using WinHex, I recover 153 files. The beta also gives 153 files but 13 or so are different. By different here I mean they are in the beta set but not in the WinHex set. That of course also means that the WinHex set has 13 that are not in the beta set!

To try and figure this out, I tried two utilities that allow the image to be mounted. The first was OSFMount by OSForensics. This showed an empty folder, ie none of the 153 files could be recovered. The second was the NTFS Reader by DiskInternals. It produced a similar set to the WinHex set but with a dozen or so different again. In short and excluding OSFMount, I have 3 different sets of recovered files. The beta had files that were not in either of the other two sets and which did not look to belong in the folder. The mft records for the files don't appear to be unusual and look to be straightforward if anything.

I'm open to suggestions as to what might produce the best base reference. Maybe I need to go back to the original drive?

Ddan

Hi Ddan,

It's difficult to dig in deep without seeing the actual problem / data.
Any chance you can share the image file, for me to look at ?

Peter

To try and figure this out, I tried two utilities that allow the image to be mounted.
Ddan

What's weird about this is that mounting an image (to me) means that Windows treats it as a normal drive and hence Windows NTFS file system drivers are responsible for the result you see ??

Different behaviour for the two drivers makes it even stranger then ?

Hi Ddan,

It's difficult to dig in deep without seeing the actual problem / data.
Any chance you can share the image file, for me to look at ?

Peter

Sorry the image is of an 80gb drive which doesn't belong to me. I'm happy to use the image for checking purposes but can't release it.

I will send you some more detailed information though which should allow you to find the bug.

Ddan

[quote="CyberGonzo]What's weird about this is that mounting an image (to me) means that Windows treats it as a normal drive and hence Windows NTFS file system drivers are responsible for the result you see ??

That should have been true for the OSFMount utility, but I don't think it would be for the NTFS Reader. The Reader is designed for use on Win95, Win98 and WinMe, which would not have NTFS, so I assume it has an internal driver.

It seems to be very complex and at the moment I cannot see the wood for the trees! I've realised that part of the problem is caused by WinHex extracting all the files that it lists, even ones that have been deleted. Also, the IsoBuster beta seems to pick up files that are not found by the others and are not present on the actual disk. This might be explained by using the INDX records rather than just the MFT? Another consequence of this is that during extraction, it occasionally throws up a duplicate file to give a 'file already exists' error. The beta also does not find some files that the others do, for unknown reasons.

Putting it into context though, I'm talking about 50 or so files in 30,000.

Ddan