I have a filter driver, and it had a problem at a customer site (evaluating our product of course!) where when they saved a microsoft office document, they would get an error, and only a zero byte file created (destroying their document). notepad, wordpad, most every other application I tried worked properly. Whith closer examination I noticed the file WAS being written to the share, but as a {tmpname.tmp} file, and then the rename to the correct name was failing.
While I tried to convince my management I was protecting their document from anyone reading it, somehow management didn’t accept that as the answer.
At any rate, I could never reproduce the problem on any test machine, and the company wouldn’t let me come put a debugger on their machine, so whats a guy to do?
Never found the problem until …
This week our CFO called me in (that’s never good), Credzba she says, when we save our finance data to disk, the files end up zero length.
GREAT I say! … She was less excited.
Anyway, it was quick to find once I had a test, in fact I was issuing a error message in my driver.
In the PreSetInformation callback, I was checking for a rename operation like this:
switch ( Data->Iopb->Parameters.SetFileInformation.FileInformationClass ) {
…
case FileRenameInformation:
PFLT_FILE_NAME_INFORMATION nameInfo;
PFILE_RENAME_INFORMATION info = (PFILE_RENAME_INFORMATION)Data->Iopb->Parameters.SetFileInformation.InfoBuffer;
status = FltGetDestinationFileNameInformation( FltObjects->Instance,
FltObjects->FileObject, info->RootDirectory,
info->FileName, info->FileNameLength,
FLT_FILE_NAME_NORMALIZED|FLT_FILE_NAME_QUERY_DEFAULT,
&nameInfo );
FILE_FILTER_ACTION action;
if (! NT_SUCCESS(status) )
{
TRACE( DL_WARNING, “Error %X getting rename info for %wZ”,
status, stream->GetFilePath() );
action = FILE_FILTER_ACTION_DENY;
… deny the operation
}
I was trying to get the too name, as it was a rename operation and I neaded to do some checking on the pre/post names in the rename operation.
The problem was (is) that the FltGetDestinationFileNameInformation is failing with C0000022 STATUS_ACCESS_DENIED.
The reason we couldn’t reproduce this was it only seems to fail if the io is on a network share with privileges and security setup such that our access is through “Authorized Users”.
There is some other security requirements that must be involved, because even seeing the share permissions, and the account logged in, I could not replicate it on another share/userid.
I had to copy the failing userid, and use the failing mount point to be able to test (again much to my CFO’s dislike… something about devs testing on corporate financial data? who’d a thought?)
Anyway, I can work around the problem now that I know what it is, but I’d REALLY like to know what the root cause is.
Until the CFO fires me or kicks me off her server I am going to keep researching this, but any help from the OSR filter manager gurus would be much appreciated.
Is there some special permission FltGetDestinationFileNameInformation requires that a normal file system rename would not?