> I looked at it for less than a minute and found 2 BSODs and 4 different ways
the output file can be corrupt.
Lemme try if I am as good as you:
-
There is no check if ExAllocatePool succeeds or not.
Try to do this under driver verifier and you get BSOD ocassionally
-
The code overwrites the target file first, then tries to
open the source file. So if source file does not exist, you get
an error but target file will be gone.
-
The “ZwWriteFile” call writes a “safeWrite” number of bytes,
where does that come from ?
-
I am not sure if the target file will have the FILE_APPEND_DATA
flag. In that case, specifying NULL as file offset in ZwWriteFile
looks dangerous to me.
-
The code does not check the result of ZwReadFile, so there is
possibility to write previous 128 bytes again to the target file
-
The “byteOffset.LowPart+=128;” is wrong. What if the file
is bigger than 4GB ?
-
There is no reentrancy in Create, but there is possible reentrancy
in read and write, but I am not sure how big problem this is.
It probably depends on where would the copy code be placed.
Hmm. Can’t find the second BSOD, so I am not that good 
L.
Second BSOD would be freeing non existant handles.
Thank you very very much for this help, ill fix this function as good as i
can and come up with a fixed one soon!
Daniel
----- Original Message -----
From: “Ladislav Zezula”
To: “Windows File Systems Devs Interest List”
Sent: Monday, October 01, 2007 9:06 AM
Subject: Re[2]: [ntfsd] Wrote a File Copy Function for all who are
intrested.
>> I looked at it for less than a minute and found 2 BSODs and 4 different
>> ways
>> the output file can be corrupt.
>
> Lemme try if I am as good as you:
>
> 1) There is no check if ExAllocatePool succeeds or not.
> Try to do this under driver verifier and you get BSOD ocassionally
>
> 2) The code overwrites the target file first, then tries to
> open the source file. So if source file does not exist, you get
> an error but target file will be gone.
>
> 3) The “ZwWriteFile” call writes a “safeWrite” number of bytes,
> where does that come from ?
>
> 4) I am not sure if the target file will have the FILE_APPEND_DATA
> flag. In that case, specifying NULL as file offset in ZwWriteFile
> looks dangerous to me.
>
> 5) The code does not check the result of ZwReadFile, so there is
> possibility to write previous 128 bytes again to the target file
>
> 6) The “byteOffset.LowPart+=128;” is wrong. What if the file
> is bigger than 4GB ?
>
> 7) There is no reentrancy in Create, but there is possible reentrancy
> in read and write, but I am not sure how big problem this is.
> It probably depends on where would the copy code be placed.
>
> Hmm. Can’t find the second BSOD, so I am not that good
>
> L.
>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@web.de
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Good work
The second BSOD (that I noticed…I’m sure there are more) is an
INVALID_KERNEL_HANDLE on the ZwClose if one of the opens fails.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: Monday, October 01, 2007 1:06 AM
To: Windows File Systems Devs Interest List
Subject: Re[2]: [ntfsd] Wrote a File Copy Function for all who are
intrested.
I looked at it for less than a minute and found 2 BSODs and 4
different ways the output file can be corrupt.
Lemme try if I am as good as you:
-
There is no check if ExAllocatePool succeeds or not.
Try to do this under driver verifier and you get BSOD ocassionally
-
The code overwrites the target file first, then tries to
open the source file. So if source file does not exist, you get
an error but target file will be gone.
-
The “ZwWriteFile” call writes a “safeWrite” number of bytes,
where does that come from ?
-
I am not sure if the target file will have the FILE_APPEND_DATA
flag. In that case, specifying NULL as file offset in ZwWriteFile
looks dangerous to me.
-
The code does not check the result of ZwReadFile, so there is
possibility to write previous 128 bytes again to the target file
-
The “byteOffset.LowPart+=128;” is wrong. What if the file
is bigger than 4GB ?
-
There is no reentrancy in Create, but there is possible reentrancy
in read and write, but I am not sure how big problem this is.
It probably depends on where would the copy code be placed.
Hmm. Can’t find the second BSOD, so I am not that good
L.
NTFSD is sponsored by OSR
For our schedule debugging and file system seminars (including our new fs
mini-filter seminar) visit:
http://www.osr.com/seminars
You are currently subscribed to ntfsd as: xxxxx@privtek.com To unsubscribe
send a blank email to xxxxx@lists.osr.com
Look at the RYO model that OSR provides about how to copy a file by building and sending IRP’s to the FS.
The RYO sample referenced above is a good model for you to follow, and would
improve your code quite a bit, however in this particular instance rolling
your own IRP’s probably would not be your best option.
Using IoCreateFileSpecifyDeviceObjectHint is allowing you to avoid re-entry
on your creates already, which you have implemented.
With that function in use, for your outlined method - ZwRead/Write should be
sufficient combined with the above create function. Rolling your own IRP’s
is generally something that looks easier than it is to get right for a
beginner. Even with that said, in your case I doubt that would even be
necessary.
Regarding file attributes, file size, copy lengths, etc., the above would be
a good example for you to look at. It would also improve on your error
handling.
On 10/2/07, xxxxx@gmail.com wrote:
>
> Look at the RYO model that OSR provides about how to copy a file by
> building and sending IRP’s to the FS.
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>