Pierre Schweitzer

Quad not because of the size, but because of the word size. sizeof(WORD) = 2, sizeof(DOUBLEWORD) = 4, sizeof(QUADWORD) = 8. OK, it can be quite confusing!

Quad not because of the size, but because of the word size. sizeof(WORD) = 2, sizeof(DOUBLEWORD) = 4, sizeof(QUADWORD) = 8.
OK, it can be quite confusing!

Yes. Sorry I could have been more explicit. That's indeed the number of arguments that I don't really like. But I could see later on that, it's not the only function like this. Perhaps in a second ...

Yes. Sorry I could have been more explicit. That's indeed the number of arguments that I don't really like. But I could see later on that, it's not the only function like this. Perhaps in a second step it would make sense to think about how to reduce these "big" functions. Nothing urgent though (this is why I didn't mark it as "unresolved").

This code was here before I started working on NTFS (9y ago - I feel old...)! Feel free to fix it.

This code was here before I started working on NTFS (9y ago - I feel old...)!
Feel free to fix it.

OK, sounds legit. Keep it that way.

OK, sounds legit. Keep it that way.

It's a "standard" quad align. For readability, perhaps it would be worth to define and a use a QuadAlign() macro, as you can find in rxprocs.h

It's a "standard" quad align. For readability, perhaps it would be worth to define and a use a QuadAlign() macro, as you can find in rxprocs.h

Fisheye isn't the place for such comments. Please refrain.

Fisheye isn't the place for such comments. Please refrain.

Yes.... https://msdn.microsoft.com/en-us/library/windows/hardware/ff539215(v=vs.85).aspx
Well, for file records, I believe this should be an acceptable risk. Unless there's a really dramatic implementation failure in NTFS, it shouldn't happen. Whereas it would really save performances....

Well, for file records, I believe this should be an acceptable risk. Unless there's a really dramatic implementation failure in NTFS, it shouldn't happen. Whereas it would really save performances.
You have two opinions Trevor, pick the one you believe is the more appropriate! :-D

It refers to the $FILE_NAME attribute. That's all. It's correct.

It refers to the $FILE_NAME attribute. That's all. It's correct.

Actually, to be even more accurate: take example on RDBSS/RXCE (<3), use BooleanFlagOn/FlagOn when possible

Actually, to be even more accurate: take example on RDBSS/RXCE (<3), use BooleanFlagOn/FlagOn when possible

And fix your coding style! :-p

And fix your coding style! :-p

Use "normalized" MS types.

Use "normalized" MS types.

Ditto. Actually, in registry (for later improvement), volumes should be specified instead of a general setting.

Ditto. Actually, in registry (for later improvement), volumes should be specified instead of a general setting.

You should check type, just in case.

You should check type, just in case.

Semi magic! See Windows Internals 4th edition, page 734. But yeah, a define might be better (my fault!).

Semi magic! See Windows Internals 4th edition, page 734. But yeah, a define might be better (my fault!).

I'm wondering how sane this...

I'm wondering how sane this...

You leak memory here

You leak memory here

I'm wondering about a lookaside allocation for file records... Would help with performances. Just my two cents for later (not to do now!)

I'm wondering about a lookaside allocation for file records... Would help with performances.
Just my two cents for later (not to do now!)

This function would be better in mft.c or some file like that.

This function would be better in mft.c or some file like that.

Avoid DbgPrint() calls, prefer our DPRINT/DPRINT1 macros

Avoid DbgPrint() calls, prefer our DPRINT/DPRINT1 macros

Why pushing for calling _HalpEndSoftwareInterrupt2? You could leave stack as it, and directly call the function? Or stdcall doesn't allow this? That would allow reducing this file, and the impact...

Why pushing for calling _HalpEndSoftwareInterrupt2? You could leave stack as it, and directly call the function?

Or stdcall doesn't allow this?

That would allow reducing this file, and the impact of such "redirection".

To demonstrate my point: https://gist.github.com/HeisSpiter/b166020bc5e4ec4c31e096f5c7db1c89

Basically, unless I totally misread your code, you never deal with Cc here (which explains the amazing performances of the whole driver). The driver just initializes Cc for each FO, to avoid issues...

Basically, unless I totally misread your code, you never deal with Cc here (which explains the amazing performances of the whole driver).
The driver just initializes Cc for each FO, to avoid issues, but never relies on Cc for RW operations. Thus, you cannot anything from Cc.

Shouldn't it be *RealLengthWritten += WriteLength;?

Shouldn't it be *RealLengthWritten += WriteLength;?

This looks really weird to me. Why did you put that check that early? There's an advantage right now of not failing immediately with FILE_CREATE: if the file already exists, we can return appropri...

This looks really weird to me.

Why did you put that check that early?
There's an advantage right now of not failing immediately with FILE_CREATE: if the file already exists, we can return appropriate error code.

On a side note, keeping current structure (without that early check) will make it easier when implementing the complete support for writing. As it is already in the rights places for checking requested disposition.This looks really weird to me.

Redundant, see line 637

Redundant, see line 637

Wow! Keep it easy with \n

Wow! Keep it easy with \n

You should check this way before, ie, when you enter the function.

You should check this way before, ie, when you enter the function.

Same

Same

Same

Same

Same

Same