Two issues found when testing the NTFS driver

Project:JNode Core
Category:feature request
Assigned:Daniel Noll

Two issues found when testing the NTFS driver on real disk images.

1. Sparse files (non-resident attribute data runs with a
cluster number of 0) aren't handled at all.

2. Highly fragmented files and indexes (e.g. directories)
result in an $ATTRIBUTE_LIST attribute, which isn't
handled at all.

I have a patch for these, which I'm currently testing.

Missing method


It's seems that 2 methods are missing to (getInt16 and getInt24), i have added them manually. Could you provide also your unit test classes ?

Thanks in advance,

EDIT : patch tested and commited to svn

Fabien L.


Eep, sorry about those missing methods, I had them already for some other patch and forgot. Smiling

Unit test class coming in a moment.

Done. Accidentally left

Done. Accidentally left the class extending from DataTestCase though. Just change that to JUnit's TestCase and hopefully things should work (at least, there are no other imports that belong to us. Laughing out loud)

Unit test commited


I have commit your unit test under org.jnode.test.fs.ntfs.NTFSUnitTest. I made some changes, you can take a look on it and feel free to comments Smiling. I have'nt commit disk image files, i want advice from others developers to know if we commit these files to SVN or not (Ewout, Levente, Fabien D. ?).

Fabien L.

One piece of advice

Just one thing to say about the unit tests:

Instead of catching exceptions in the unit tests, it would be better if the test methods throw Exception. This way, when the test fails, JUnit will print the full stack trace. With the code the way it is right now, it will only print the message, which won't help when it comes to finding out what actually went wrong.


Unit test never throws exceptions, when you unit test something exception means test fail, if you throw exception, i think that JUnit doesn't run other test methods. But We can make special unit test methods to test exception cases and/or return full stack trace instead of only exception message.

Fabien L.

You're half right.

You're half right.

An exception does mean that a test fails -- that's the entire point of declaring the method to throw Exception. But where you're wrong is that JUnit *does* run the other tests.

Here's another way to think about it: by catching the exception and calling fail(), all you've achieved is that now, the method throws an AssertionFailedError instead of an IOException. Either way, JUnit catches it.

Status check

Are these all committed now? Can the bug be closed?


Status:active» patch (code needs review)



issues_6 is a gzipped disk image with sparse files in it.
issues_7 is a gzipped disk image with a highly fragmented file in it.


Patch here. Description of changes:

For sparse files:
* Modified DataRun to support lengths and offsets of 0. Offsets of 0 are handled as sparse data. Lengths of 0 I've never seen IRL, so I wouldn't know what to do.

For highly fragmented data:
* Support for $ATTRIBUTE_LIST, both resident and non-resident. The fact that I needed to make two classes for this indicates a possible problem with the current OO design.

You can test this against the two provided disk images above, they both work.

Incidentally, is there a convenient means of including unit tests in the repository itself? I've noticed that the existing unit tests refer to some E: which doesn't exist. Smiling


Sparse file disk image -- same gzipped image but without the partition table, makes it easier to use with Jnode's FileDevice.


Extremely fragmented disk image -- same gzipped image but without the partition table, makes it easier to use with Jnode's FileDevice.


Here's the unit test I'm running. The package is still in our company's namespace but rename it to whatever you want. I think I took out all of the code which related to our own unit test framework.


Title:Two issues found when testing the NTFS dri» Two issues found when testing the NTFS driver
Status:patch (code needs review)» closed

Given that this got applied, closing.