Hi,
I have a file system driver which worked fine until lately that upon dragging and dropping a file from a directory (on the file system) to Visual Studio (to open as a binary file) I receive a nice windows that declares: “Handle does not support synchronous operations”.
What is my driver doing wrong that files cannot be opened synchronously?
The above is applied on a windows 7 64bit system.
Igal
This is an error I’ve never seen before. When you finish the create, is the FO_SYNCHRONOUS_IO bit set?
Have you collected any traces of the behavior on NTFS and then on your file system and compare them?
Tony
OSR
Tony,
thanks for the reply, I am not sure I know how to collect the traces from NTFS.
Though I have noticed that when I CreateFile (in user mode application) I receive a “good” handle, then if I ReadFile then I received the INVALID_PARAMETER (87d) error (from GetLastError). I have set break points in all positions in the file system that returns this value and the driver never “break”.
Moreover the IRP_MJ_READ is not received.
But then I set the SetFilePointer to the beginning of the file (right after CreateFile), and I successfully read the file.
Moreover when drugging the file to an explorer directory it copies the file just fine.
Regarding your question about the FO_SYNCHRONOUS_IO, I do not set it during/after Create.
Igal
Procmon, filespy, minispy, irptracker, etc.
The I/O Manager is rejecting the request then it sounds like.
I’m not sure why that changes the behavior. Interesting.
I actually was more subtle in my question: I asked if it was set. I’m trying to ascertain why you would see this error.
Here’s another question then: do you update FileObject->CurrentByteOffset? If so, when do you update it? Do you use the value of this fiel anywhere in your file system?
Tony
OSR
Tony,
It seems like the problem is involving the CurrentByteOffset parameter.
When I try to get file’s position (SetFilePointer(hFile, 0, NULL, FILE_CURRENT)
I receive -1 :(.
During file creation the CurrentByteOffset in the Ccb is set to zero.
Upon IRP_MJ_QUERY_INFORMATION query (which is invoked right after file openning) I verified that I return CurrentByteOffset = 0; Though this function is invoked without space for the file name so I reply with STATUS_BUFFER_OVERFLOW.
Is there anything else that I am doing wrong?
Igal
Are you returning STATUS_BUFFER_TOO_SMALL for the
FilePositionInformation class type of an IRP_MJ_QUERY_INFORMATION? There
would be no file name returned in this case, just a
FILE_POSITION_INFORMATION structure. If you are handling a
FileAllInformation class type request, then you fill in as much
information as you can, assuming the passed in buffer can hold some of
the information.
Let us know which class type you are handling and having to provide the
file name.
Pete
On 2/9/2014 10:38 AM, igalk013@013.net.il wrote:
Tony,
It seems like the problem is involving the CurrentByteOffset parameter.
When I try to get file’s position (SetFilePointer(hFile, 0, NULL, FILE_CURRENT)During file creation the CurrentByteOffset in the Ccb is set to zero.
Upon IRP_MJ_QUERY_INFORMATION query (which is invoked right after file openning) I verified that I return CurrentByteOffset = 0; Though this function is invoked without space for the file name so I reply with STATUS_BUFFER_OVERFLOW.
Is there anything else that I am doing wrong?
Igal
NTFSD is sponsored by OSR
OSR is hiring!! Info at http://www.osr.com/careers
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Pete,
I was returning STATUS_BUFFER_OVERFLOW but I have updated it to STATUS_BUFFER_OVERFLOW.
I am handling the FileAllInformation and this is what I return after filling all other structures and realizing that the buffer for the FileName is too small:
Irp->IoStatus.Information = sizeof(FILE_ALL_INFORMATION);
FileNameInformation->FileNameLength = Fcb->NCMcb->ShortName.Length;
FileNameInformation->FileName[0] = Fcb->NCMcb->ShortName.Buffer[0];
Status = STATUS_BUFFER_TOO_SMALL;
Igal
Pete,
Sorry I have updated the status to STATUS_BUFFER_TOO_SMALL.
Igal
Guys,
any ideas?
Igal
Per Tony’s suggestion, collect some trace from NTFS using FileSpy or
similar when you are not running and compare it to a trace collected
when your filter is in place.
Pete
On 2/12/2014 3:45 AM, igalk013@013.net.il wrote:
Guys,
any ideas?
Igal
NTFSD is sponsored by OSR
OSR is hiring!! Info at http://www.osr.com/careers
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Pete,
thanks, but I think that I am getting the correct IRPs.
The problem is that I am setting CurrentByteOffset to 0, but when I read the SetFilePointer I am getting a number like 0x0051EDF8_FFFFFFFF, instead of 0.
I was trying to look inside the structures which are returned from the CreateFile IRPs and found no traces for a number like this.
What other fields should I set for “current file pointer” during creation?
BTW, in user mode the functions that I run are CretaeFile and then SetFilePointer (to get current position) and If I set the current file to 0 (from user mode) every thing runs great.
thanks,
Igal.
SetFilePointer() will set the CBO and then return the new pointer. When
you call it to ‘read’ the pointer position, what are you setting it to?
Also, are you seeing this request in your filter?
On completion of the open, in post-create, you can see the CBO value in
the FO but you should not be altering this value.
Pete
On 2/12/2014 9:59 AM, igalk013@013.net.il wrote:
Pete,
thanks, but I think that I am getting the correct IRPs.
The problem is that I am setting CurrentByteOffset to 0, but when I read the SetFilePointer I am getting a number like 0x0051EDF8_FFFFFFFF, instead of 0.I was trying to look inside the structures which are returned from the CreateFile IRPs and found no traces for a number like this.
What other fields should I set for “current file pointer” during creation?
BTW, in user mode the functions that I run are CretaeFile and then SetFilePointer (to get current position) and If I set the current file to 0 (from user mode) every thing runs great.
thanks,
Igal.
NTFSD is sponsored by OSR
OSR is hiring!! Info at http://www.osr.com/careers
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
I still don’t see a clear answer to whether the FILE_OBJECT has the
FO_SYNCHRONOUS_IO set. This flag controls the behavior of CurrentByteOffset
and it makes sense that your SetFilePointer() call would fail if called on
a file that doesn’t have it set (see my post about this flag here:
http://fsfilters.blogspot.com/2012/06/flags-of-fileobjects-part-i.html).
So could you please make sure it’s set in the FILE_OBJECT during
IRP_MJ_CREATE ?
Thanks,
Alex.
On Wed, Feb 12, 2014 at 9:06 AM, Peter Scott wrote:
>
> SetFilePointer() will set the CBO and then return the new pointer. When
> you call it to ‘read’ the pointer position, what are you setting it to?
> Also, are you seeing this request in your filter?
>
> On completion of the open, in post-create, you can see the CBO value in
> the FO but you should not be altering this value.
>
> Pete
>
>
> On 2/12/2014 9:59 AM, igalk013@013.net.il wrote:
>
>> Pete,
>>
>> thanks, but I think that I am getting the correct IRPs.
>> The problem is that I am setting CurrentByteOffset to 0, but when I read
>> the SetFilePointer I am getting a number like 0x0051EDF8_FFFFFFFF, instead
>> of 0.
>>
>> I was trying to look inside the structures which are returned from the
>> CreateFile IRPs and found no traces for a number like this.
>>
>> What other fields should I set for “current file pointer” during creation?
>>
>> BTW, in user mode the functions that I run are CretaeFile and then
>> SetFilePointer (to get current position) and If I set the current file to 0
>> (from user mode) every thing runs great.
>>
>> thanks,
>>
>> Igal.
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> OSR is hiring!! Info at http://www.osr.com/careers
>>
>> For our schedule of debugging and file system seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> –
> Kernel Drivers
> Windows File System and Device Driver Consulting
> www.KernelDrivers.com
> 866.263.9295
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Pete,
here is the code that I invoke to get current file’s position:
LARGE_INTEGER val;
HANDLE handle = CreateFile( “J:\VIDEO\CHANNEL_1\VID_1_0000.mp4”,
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
0,
NULL );
DWORD err = GetLastError();
if ( handle == INVALID_HANDLE_VALUE )
{
return;
}
val.LowPart = SetFilePointer(hFile, 0, &val.HighPart, FILE_CURRENT);
I do not see any incocation of the file system driver upon SetFilePointer invocation.
After the CreateFile I “watched” the CBO in FO and it was zero(!!!).
this is how I set it:
IrpSp->FileObject->CurrentByteOffset.QuadPart = 0LL;
Alex,
Who supposed to set the flag FO_SYNCHRONOUS_IO in FO the file system driver ( I am) or the IO Manager? I did not see any fastfat driver any reference to this flag ,but in read and write functions.
I will test it later today.
Thanks, guys,
Igal
> Pete,
here is the code that I invoke to get current file’s position:
LARGE_INTEGER val;
HANDLE handle = CreateFile( “J:\VIDEO\CHANNEL_1\VID_1_0000.mp4”,
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
0,
NULL );
DWORD err = GetLastError();
if ( handle == INVALID_HANDLE_VALUE )
{
Note that calling GetLastError() if you don’t know that there has been a
failure means that the value in err is nonsense. It is defined, with rare
exceptions, ONLY IF the API call has failed (there are a small list of
special exceptions, such as creating a named kernel object). But
CreateFile is not one of the APIs for which GetLastError() is defined if
it succeeds.
The line should be moved to inside the current block, so there is no
temptation to user or depend on the ‘err’ value anywhere else in the code.
It might also be useful to do some debug printout here.
return;
}
val.LowPart = SetFilePointer(hFile, 0, &val.HighPart, FILE_CURRENT);
Use SetFilePointerEx so you don’t have to deal with the idiocy of these
split 32-bit references.
I do not see any incocation of the file system driver upon SetFilePointer
invocation.
After the CreateFile I “watched” the CBO in FO and it was zero(!!!).
this is how I set it:
IrpSp->FileObject->CurrentByteOffset.QuadPart = 0LL;
Strictly speaking, you didn’t need the LL after the 0, since the compiler
is smart enough to widen the simple 0 constant to be the right size.
Alex,
Who supposed to set the flag FO_SYNCHRONOUS_IO in FO the file system
driver ( I am) or the IO Manager? I did not see any fastfat driver any
reference to this flag ,but in read and write functions.
I will test it later today.Thanks, guys,
Igal
NTFSD is sponsored by OSR
OSR is hiring!! Info at http://www.osr.com/careers
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
LARGE_INTEGER val;
…
val.LowPart = SetFilePointer(hFile, 0, &val.HighPart, FILE_CURRENT);
Are you really not initializing val? Note that the HighPart parameter is an
Inout, so you’re setting the high part of the offset to a garbage value:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365541(v=vs.85).aspx
Which would explain that problem.
Correct. This processing is all handled internally by the I/O Manager
without involving the file system.
The I/O Manager sets it.
-scott
OSR
wrote in message news:xxxxx@ntfsd…
Pete,
here is the code that I invoke to get current file’s position:
LARGE_INTEGER val;
HANDLE handle = CreateFile( “J:\VIDEO\CHANNEL_1\VID_1_0000.mp4”,
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
0,
NULL );
DWORD err = GetLastError();
if ( handle == INVALID_HANDLE_VALUE )
{
return;
}
val.LowPart = SetFilePointer(hFile, 0, &val.HighPart, FILE_CURRENT);
I do not see any incocation of the file system driver upon SetFilePointer
invocation.
After the CreateFile I “watched” the CBO in FO and it was zero(!!!).
this is how I set it:
IrpSp->FileObject->CurrentByteOffset.QuadPart = 0LL;
Alex,
Who supposed to set the flag FO_SYNCHRONOUS_IO in FO the file system driver
( I am) or the IO Manager? I did not see any fastfat driver any reference to
this flag ,but in read and write functions.
I will test it later today.
Thanks, guys,
Igal
Alex,
The FO_SYNCHRONOUS_IO is set: IrpSp->FileObject->Flags = 2
Joseph,
I have implemented your notes.
Scott,
I have fixed the initialization of LARGE_INTEGER and now I get 0x00000000_FFFFFFFF as the current position right after CreateFile.
So do you think that I should initialize anything else, to make the file system return offset system upon file creation?
Igal
I don’t think 0x00000000_FFFFFFFF is actually the position. Instead I think
you got an error. According to the documentation:
If the function fails, the return value is *INVALID_SET_FILE_POINTER*. To
get extended error information,
call*GetLastError*http:.
(and yes, INVALID_SET_FILE_POINTER is -1).
Also, there is another interesting bit in the documentation:
Note Because INVALID_SET_FILE_POINTER is a valid value for the
low-order DWORD of the new file pointer, you must check both the return
value of the function and the error code returned by
GetLastErrorhttp:
to
determine whether or not an error has occurred. If an error has occurred,
the return value of SetFilePointer isINVALID_SET_FILE_POINTER and
GetLastError returns a value other than NO_ERROR. For a code example
that demonstrates how to check for failure, see the Remarks section in this
topic.
So could you implemented the code as in the example from the SetFilePointer
page (
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365541(v=vs.85).aspx
)?
// Try to move hFile file pointer a huge distance
DWORD dwPtrLow = SetFilePointer( hFile,
lDistLow,
&lDistHigh,
FILE_BEGIN );
// Test for failure
if ( dwPtrLow == INVALID_SET_FILE_POINTER &&
GetLastError() != NO_ERROR )
{
// Deal with failure
// . . .
} // End of error handler
If you’ve already changed your code to use SetFilePointerEx(), could you
please paste the new code ?
Thanks,
Alex.
On Thu, Feb 13, 2014 at 9:19 AM, wrote:
> Alex,
>
> The FO_SYNCHRONOUS_IO is set: IrpSp->FileObject->Flags = 2
>
> Joseph,
> I have implemented your notes.
>
> Scott,
>
> I have fixed the initialization of LARGE_INTEGER and now I get
> 0x00000000_FFFFFFFF as the current position right after CreateFile.
>
> So do you think that I should initialize anything else, to make the file
> system return offset system upon file creation?
>
> Igal
>
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
></http:></http:>
The Win32 API really baffles me.
-scott
OSR
“Alex Carp” wrote in message
news:xxxxx@ntfsd…
I don’t think 0x00000000_FFFFFFFF is actually the position. Instead I think
you got an error. According to the documentation:
If the function fails, the return value is INVALID_SET_FILE_POINTER. To get
extended error information, callGetLastError. (and yes,
INVALID_SET_FILE_POINTER is -1).
Also, there is another interesting bit in the documentation:
Note Because INVALID_SET_FILE_POINTER is a valid value for the low-order
DWORD of the new file pointer, you must check both the return value of the
function and the error code returned by GetLastError to determine whether or
not an error has occurred. If an error has occurred, the return value of
SetFilePointer isINVALID_SET_FILE_POINTER and GetLastError returns a value
other than NO_ERROR. For a code example that demonstrates how to check for
failure, see the Remarks section in this topic.
So could you implemented the code as in the example from the SetFilePointer
page
(http://msdn.microsoft.com/en-us/library/windows/desktop/aa365541(v=vs.85).aspx)?
// Try to move hFile file pointer a huge distance DWORD dwPtrLow =
SetFilePointer( hFile, lDistLow, &lDistHigh, FILE_BEGIN ); // Test for
failure if ( dwPtrLow == INVALID_SET_FILE_POINTER && GetLastError() !=
NO_ERROR ) { // Deal with failure // . . . } // End of error handler
If you’ve already changed your code to use SetFilePointerEx(), could you
please paste the new code ?
Thanks,
Alex.
On Thu, Feb 13, 2014 at 9:19 AM, wrote:
Alex,
The FO_SYNCHRONOUS_IO is set: IrpSp->FileObject->Flags = 2
Joseph,
I have implemented your notes.
Scott,
I have fixed the initialization of LARGE_INTEGER and now I get
0x00000000_FFFFFFFF as the current position right after CreateFile.
So do you think that I should initialize anything else, to make the file
system return offset system upon file creation?
Igal
—
NTFSD is sponsored by OSR
OSR is hiring!! Info at http://www.osr.com/careers
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Alex,
The error that I get is 131 which means (An attempt was made to move the file pointer before the beginning of the file.), trust me I do not do it intentionally.
Any ideas?
Igal