feat/added_ignore_dos_flag_to_mft_plugin

[B0TAxy]

This change adds a new --ignore-dos flag to the MFT plugin. This allows users to filter out short DOS 8.3 filenames from the output, focusing only on long filenames. The update adds the argument to the CLI, updates the records method signature to handle the new boolean flag, and ensures the path resolution logic respects this setting when generating file paths.

[Schamper]

Would you mind adding a small unit test? I believe we have a small MFT in the test data, I hope it has DOS names.

[B0TAxy]

Would you mind adding a small unit test? I believe we have a small MFT in the test data, I hope it has DOS names.

I’ve checked the MFT files in our test data, but unfortunately, they don't appear to contain any DOS names. Do you happen to have a different MFT sample with DOS names that I could use for this test?

[Schamper]

Unfortunately not, but it looks like you can use fsutil setshortname: http://technet.microsoft.com/en-us/library/bb490642.aspx

Perhaps you could make a small test disk and use that.

[B0TAxy]

Unfortunately not, but it looks like you can use fsutil setshortname: http://technet.microsoft.com/en-us/library/bb490642.aspx

Perhaps you could make a small test disk and use that.

I ended up scripting a synthetic MFT record to create the test case manually. I also tested this against a vmdk image and can see the DOS names persisting there as well, which confirms a gap in the current detection logic.

Do you want to look into this, or would you prefer I dig deeper and propose a fix myself?

[Schamper]

Do you want to look into this, or would you prefer I dig deeper and propose a fix myself?

Look into what exactly? It's not entirely clear to me what you're referring to.

[B0TAxy]

Do you want to look into this, or would you prefer I dig deeper and propose a fix myself?

Look into what exactly? It's not entirely clear to me what you're referring to.

There is a bug in the detection logic for DOS names and it isn't working properly. We need to investigate dissect.ntfs more deeply to find exactly where the breakdown is.
How would you like to proceed with this PR given the situation? Should I keep it open while I dig into the fix, or would you prefer I open a separate issue and we handle it there?

[Schamper]

It's fine to keep this open. When you have more information available you can open a issue or PR on dissect.ntfs.