Filter manager name cache not correct in presence of transactions

Gentlefolk

I seem to have found a bug in filter manager in WSL Feb CTP. The problem is
that the name cache is not correct in the presence of transactions.

I have pasted below a test function (user mode) [outlook has messed up
indent]. I call this function with filename = “e:\testdir\testfile” and flag
as either TRUE or FALSE.

If I call with flag TRUE then a call to …

FltGetFileNameInformation(CallbackData, FLT_FILE_NAME_NORMALIZED |
FLT_FILE_NAME_QUERY_DEFAULT, &FileNameInformation);

… in post create for the final create file after the transaction has been
commit returns \testdir\testfile which is incorrect instead of
\testdir\testfile_new which is correct. If I call the test function with
flag FALSE then the correct name is returned from FltGetFileNameInformation.
The FltObjects->FileObject->FsContext in all the IRP_MJ_CREATE and
IRP_MJ_SET_INFORMATION FileRenameInformation due to test function are all
observed to have the same value.

I’d be grateful if MSFT could confirm.

Cheers
Lyndon
VOID DoChuckle(WCHAR * filename, BOOL flag)

{

HANDLE hTransaction;

HANDLE hFile;

WCHAR filename_new[MAX_PATH];

wsprintf(filename_new, L"%s_new", filename);

DeleteFile(filename);

DeleteFile(filename_new);

fwprintf(stdout, L"filename: %s\n", filename);

fwprintf(stdout, L"filename_new: %s\n", filename_new);

fwprintf(stdout, L"CreateTransaction\n");

hTransaction = CreateTransaction(NULL, NULL, 0, 0, 0, 0, NULL);

if (hTransaction == INVALID_HANDLE_VALUE)

{

DWORD dwError = GetLastError();

fwprintf(stderr, L"CreateTransaction fails %d\n", dwError);

exit(1);

}

fwprintf(stdout, L"CreateFile [CREATE]\n");

hFile = CreateFile(filename,

GENERIC_READ | GENERIC_WRITE,

FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,

NULL,

CREATE_NEW,

FILE_ATTRIBUTE_NORMAL,

NULL);

if (hFile == INVALID_HANDLE_VALUE)

{

DWORD dwError = GetLastError();

fwprintf(stderr, L"CreateFile fails %d\n", dwError);

(void) CloseHandle(hTransaction);

exit(1);

}

(void) CloseHandle(hFile);

fwprintf(stdout, L"MoveFileTransacted\n");

if (!MoveFileTransacted(filename, filename_new, NULL, NULL,
MOVEFILE_REPLACE_EXISTING, hTransaction))

{

DWORD dwError = GetLastError();

fwprintf(stderr, L"MoveFileTransacted fails %d\n", dwError);

(void) CloseHandle(hTransaction);

exit(1);

}

if (flag)

{

fwprintf(stdout, L"CreateFile [OPEN, READ]\n");

hFile = CreateFile(filename,

GENERIC_READ,

FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,

NULL,

OPEN_EXISTING,

FILE_ATTRIBUTE_NORMAL,

NULL);

if (hFile == INVALID_HANDLE_VALUE)

{

DWORD dwError = GetLastError();

fwprintf(stderr, L"CreateFile fails %d\n", dwError);

}

(void) CloseHandle(hFile);

}

fwprintf(stdout, L"CommitTransaction\n");

if (!CommitTransaction(hTransaction))

{

DWORD dwError = GetLastError();

fwprintf(stderr, L"CommitTransaction fails %d\n", dwError);

(void) CloseHandle(hTransaction);

exit(1);

}

fwprintf(stdout, L"CreateFile [OPEN, READ] NEW\n");

hFile = CreateFile(filename_new,

GENERIC_READ,

FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,

NULL,

OPEN_EXISTING,

FILE_ATTRIBUTE_NORMAL,

NULL);

if (hFile == INVALID_HANDLE_VALUE)

{

DWORD dwError = GetLastError();

fwprintf(stderr, L"CreateFile fails %d\n", dwError);

}

(void) CloseHandle(hFile);

(void) CloseHandle(hTransaction);

}

Lyndon:

Sorry if I’m missing something obvious, but if flag is TRUE, you call
CreateFile() before you call CommitTransaction(), so it *should* still be
the old name, shouldn’t it?

Also, in the post-Create, did you check FltGetTunneledName()? Not sure if
it’s different for transacted operations, but…

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Friday, March 02, 2007 12:12 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Filter manager name cache not correct in presence of
transactions

Gentlefolk

I seem to have found a bug in filter manager in WSL Feb CTP. The problem is
that the name cache is not correct in the presence of transactions.

I have pasted below a test function (user mode) [outlook has messed up
indent]. I call this function with filename = “e:\testdir\testfile” and flag

as either TRUE or FALSE.

If I call with flag TRUE then a call to …

FltGetFileNameInformation(CallbackData, FLT_FILE_NAME_NORMALIZED |
FLT_FILE_NAME_QUERY_DEFAULT, &FileNameInformation);

… in post create for the final create file after the transaction has been

commit returns \testdir\testfile which is incorrect instead of
\testdir\testfile_new which is correct. If I call the test function with
flag FALSE then the correct name is returned from FltGetFileNameInformation.

The FltObjects->FileObject->FsContext in all the IRP_MJ_CREATE and
IRP_MJ_SET_INFORMATION FileRenameInformation due to test function are all
observed to have the same value.

I’d be grateful if MSFT could confirm.

Cheers
Lyndon
VOID DoChuckle(WCHAR * filename, BOOL flag)

{

HANDLE hTransaction;

HANDLE hFile;

WCHAR filename_new[MAX_PATH];

wsprintf(filename_new, L"%s_new", filename);

DeleteFile(filename);

DeleteFile(filename_new);

fwprintf(stdout, L"filename: %s\n", filename);

fwprintf(stdout, L"filename_new: %s\n", filename_new);

fwprintf(stdout, L"CreateTransaction\n");

hTransaction = CreateTransaction(NULL, NULL, 0, 0, 0, 0, NULL);

if (hTransaction == INVALID_HANDLE_VALUE)

{

DWORD dwError = GetLastError();

fwprintf(stderr, L"CreateTransaction fails %d\n", dwError);

exit(1);

}

fwprintf(stdout, L"CreateFile [CREATE]\n");

hFile = CreateFile(filename,

GENERIC_READ | GENERIC_WRITE,

FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,

NULL,

CREATE_NEW,

FILE_ATTRIBUTE_NORMAL,

NULL);

if (hFile == INVALID_HANDLE_VALUE)

{

DWORD dwError = GetLastError();

fwprintf(stderr, L"CreateFile fails %d\n", dwError);

(void) CloseHandle(hTransaction);

exit(1);

}

(void) CloseHandle(hFile);

fwprintf(stdout, L"MoveFileTransacted\n");

if (!MoveFileTransacted(filename, filename_new, NULL, NULL,
MOVEFILE_REPLACE_EXISTING, hTransaction))

{

DWORD dwError = GetLastError();

fwprintf(stderr, L"MoveFileTransacted fails %d\n", dwError);

(void) CloseHandle(hTransaction);

exit(1);

}

if (flag)

{

fwprintf(stdout, L"CreateFile [OPEN, READ]\n");

hFile = CreateFile(filename,

GENERIC_READ,

FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,

NULL,

OPEN_EXISTING,

FILE_ATTRIBUTE_NORMAL,

NULL);

if (hFile == INVALID_HANDLE_VALUE)

{

DWORD dwError = GetLastError();

fwprintf(stderr, L"CreateFile fails %d\n", dwError);

}

(void) CloseHandle(hFile);

}

fwprintf(stdout, L"CommitTransaction\n");

if (!CommitTransaction(hTransaction))

{

DWORD dwError = GetLastError();

fwprintf(stderr, L"CommitTransaction fails %d\n", dwError);

(void) CloseHandle(hTransaction);

exit(1);

}

fwprintf(stdout, L"CreateFile [OPEN, READ] NEW\n");

hFile = CreateFile(filename_new,

GENERIC_READ,

FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,

NULL,

OPEN_EXISTING,

FILE_ATTRIBUTE_NORMAL,

NULL);

if (hFile == INVALID_HANDLE_VALUE)

{

DWORD dwError = GetLastError();

fwprintf(stderr, L"CreateFile fails %d\n", dwError);

}

(void) CloseHandle(hFile);

(void) CloseHandle(hTransaction);

}


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

Ken

Thanks for your comment.

In post oprtaiton for the IRP_MJ_CREATE of the “CreateFile [OPEN, READ]”
*before* the transaction commit the name should of course be the old name.
This is not the problem.

In post operation for the IRP_MJ_CREATE of the “CreateFile [OPEN, READ] NEW”
*after* the transaction commit the name should of course be the *new* name.
This is the problem.

In respect of tunnel cache … I am in this test minifilter calling …

FltGetFileNameInformation(CallbackData, FLT_FILE_NAME_NORMALIZED |
FLT_FILE_NAME_QUERY_DEFAULT, &FileNameInformation);

… in post operation of IRP_MJ_CREATE and IRP_MJ_SET_INFORMATION
FileRenameInformation, this test minifilter does zero name processing in
pre-operation, and so there is no need for this test minifilter to meddle
with tunnel cache.

I hope this makes sense!

Cheers
Lyndon

“Ken Cross” wrote in message news:xxxxx@ntfsd…
> Lyndon:
>
> Sorry if I’m missing something obvious, but if flag is TRUE, you call
> CreateFile() before you call CommitTransaction(), so it should still be
> the old name, shouldn’t it?
>
> Also, in the post-Create, did you check FltGetTunneledName()? Not sure if
> it’s different for transacted operations, but…
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> Sent: Friday, March 02, 2007 12:12 PM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Filter manager name cache not correct in presence of
> transactions
>
> Gentlefolk
>
> I seem to have found a bug in filter manager in WSL Feb CTP. The problem
> is
> that the name cache is not correct in the presence of transactions.
>
> I have pasted below a test function (user mode) [outlook has messed up
> indent]. I call this function with filename = “e:\testdir\testfile” and
> flag
>
> as either TRUE or FALSE.
>
> If I call with flag TRUE then a call to …
>
> FltGetFileNameInformation(CallbackData, FLT_FILE_NAME_NORMALIZED |
> FLT_FILE_NAME_QUERY_DEFAULT, &FileNameInformation);
>
> … in post create for the final create file after the transaction has
> been
>
> commit returns \testdir\testfile which is incorrect instead of
> \testdir\testfile_new which is correct. If I call the test function with
> flag FALSE then the correct name is returned from
> FltGetFileNameInformation.
>
> The FltObjects->FileObject->FsContext in all the IRP_MJ_CREATE and
> IRP_MJ_SET_INFORMATION FileRenameInformation due to test function are all
> observed to have the same value.
>
> I’d be grateful if MSFT could confirm.
>
> Cheers
> Lyndon
> VOID DoChuckle(WCHAR * filename, BOOL flag)
>
> {
>
> HANDLE hTransaction;
>
> HANDLE hFile;
>
> WCHAR filename_new[MAX_PATH];
>
> wsprintf(filename_new, L"%s_new", filename);
>
> DeleteFile(filename);
>
> DeleteFile(filename_new);
>
> fwprintf(stdout, L"filename: %s\n", filename);
>
> fwprintf(stdout, L"filename_new: %s\n", filename_new);
>
> fwprintf(stdout, L"CreateTransaction\n");
>
> hTransaction = CreateTransaction(NULL, NULL, 0, 0, 0, 0, NULL);
>
> if (hTransaction == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateTransaction fails %d\n", dwError);
>
> exit(1);
>
> }
>
> fwprintf(stdout, L"CreateFile [CREATE]\n");
>
> hFile = CreateFile(filename,
>
> GENERIC_READ | GENERIC_WRITE,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> CREATE_NEW,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> (void) CloseHandle(hFile);
>
> fwprintf(stdout, L"MoveFileTransacted\n");
>
> if (!MoveFileTransacted(filename, filename_new, NULL, NULL,
> MOVEFILE_REPLACE_EXISTING, hTransaction))
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"MoveFileTransacted fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> if (flag)
>
> {
>
> fwprintf(stdout, L"CreateFile [OPEN, READ]\n");
>
> hFile = CreateFile(filename,
>
> GENERIC_READ,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> OPEN_EXISTING,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> }
>
> (void) CloseHandle(hFile);
>
> }
>
> fwprintf(stdout, L"CommitTransaction\n");
>
> if (!CommitTransaction(hTransaction))
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CommitTransaction fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> fwprintf(stdout, L"CreateFile [OPEN, READ] NEW\n");
>
> hFile = CreateFile(filename_new,
>
> GENERIC_READ,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> OPEN_EXISTING,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> }
>
> (void) CloseHandle(hFile);
>
> (void) CloseHandle(hTransaction);
>
> }
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

OK, I did indeed miss something obvious. :wink:

But I’m not sure you can ignore tunneling – it may be a factor here. I’ve
found the output of FltGetTunneledName() really did change depending on
circumstances (the definitions of which are very vague).

So I still ask: Did you check FltGetTunneledName()?

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Friday, March 02, 2007 1:30 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Filter manager name cache not correct in presence of
transactions

Ken

Thanks for your comment.

In post oprtaiton for the IRP_MJ_CREATE of the “CreateFile [OPEN, READ]”
*before* the transaction commit the name should of course be the old name.
This is not the problem.

In post operation for the IRP_MJ_CREATE of the “CreateFile [OPEN, READ] NEW”

*after* the transaction commit the name should of course be the *new* name.
This is the problem.

In respect of tunnel cache … I am in this test minifilter calling …

FltGetFileNameInformation(CallbackData, FLT_FILE_NAME_NORMALIZED |
FLT_FILE_NAME_QUERY_DEFAULT, &FileNameInformation);

… in post operation of IRP_MJ_CREATE and IRP_MJ_SET_INFORMATION
FileRenameInformation, this test minifilter does zero name processing in
pre-operation, and so there is no need for this test minifilter to meddle
with tunnel cache.

I hope this makes sense!

Cheers
Lyndon

“Ken Cross” wrote in message news:xxxxx@ntfsd…
> Lyndon:
>
> Sorry if I’m missing something obvious, but if flag is TRUE, you call
> CreateFile() before you call CommitTransaction(), so it should still be
> the old name, shouldn’t it?
>
> Also, in the post-Create, did you check FltGetTunneledName()? Not sure if
> it’s different for transacted operations, but…
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> Sent: Friday, March 02, 2007 12:12 PM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Filter manager name cache not correct in presence of
> transactions
>
> Gentlefolk
>
> I seem to have found a bug in filter manager in WSL Feb CTP. The problem
> is
> that the name cache is not correct in the presence of transactions.
>
> I have pasted below a test function (user mode) [outlook has messed up
> indent]. I call this function with filename = “e:\testdir\testfile” and
> flag
>
> as either TRUE or FALSE.
>
> If I call with flag TRUE then a call to …
>
> FltGetFileNameInformation(CallbackData, FLT_FILE_NAME_NORMALIZED |
> FLT_FILE_NAME_QUERY_DEFAULT, &FileNameInformation);
>
> … in post create for the final create file after the transaction has
> been
>
> commit returns \testdir\testfile which is incorrect instead of
> \testdir\testfile_new which is correct. If I call the test function with
> flag FALSE then the correct name is returned from
> FltGetFileNameInformation.
>
> The FltObjects->FileObject->FsContext in all the IRP_MJ_CREATE and
> IRP_MJ_SET_INFORMATION FileRenameInformation due to test function are all
> observed to have the same value.
>
> I’d be grateful if MSFT could confirm.
>
> Cheers
> Lyndon
> VOID DoChuckle(WCHAR * filename, BOOL flag)
>
> {
>
> HANDLE hTransaction;
>
> HANDLE hFile;
>
> WCHAR filename_new[MAX_PATH];
>
> wsprintf(filename_new, L"%s_new", filename);
>
> DeleteFile(filename);
>
> DeleteFile(filename_new);
>
> fwprintf(stdout, L"filename: %s\n", filename);
>
> fwprintf(stdout, L"filename_new: %s\n", filename_new);
>
> fwprintf(stdout, L"CreateTransaction\n");
>
> hTransaction = CreateTransaction(NULL, NULL, 0, 0, 0, 0, NULL);
>
> if (hTransaction == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateTransaction fails %d\n", dwError);
>
> exit(1);
>
> }
>
> fwprintf(stdout, L"CreateFile [CREATE]\n");
>
> hFile = CreateFile(filename,
>
> GENERIC_READ | GENERIC_WRITE,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> CREATE_NEW,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> (void) CloseHandle(hFile);
>
> fwprintf(stdout, L"MoveFileTransacted\n");
>
> if (!MoveFileTransacted(filename, filename_new, NULL, NULL,
> MOVEFILE_REPLACE_EXISTING, hTransaction))
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"MoveFileTransacted fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> if (flag)
>
> {
>
> fwprintf(stdout, L"CreateFile [OPEN, READ]\n");
>
> hFile = CreateFile(filename,
>
> GENERIC_READ,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> OPEN_EXISTING,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> }
>
> (void) CloseHandle(hFile);
>
> }
>
> fwprintf(stdout, L"CommitTransaction\n");
>
> if (!CommitTransaction(hTransaction))
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CommitTransaction fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> fwprintf(stdout, L"CreateFile [OPEN, READ] NEW\n");
>
> hFile = CreateFile(filename_new,
>
> GENERIC_READ,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> OPEN_EXISTING,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> }
>
> (void) CloseHandle(hFile);
>
> (void) CloseHandle(hTransaction);
>
> }
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

Ken

I did not check FltGetTunneledName() and to be frank I dont see a strong
reason to consider tunnel cache. I shall however, since you have been kind
enough to respond, do that next week, and post the results.

In the meantime, I think, this remains on the table as a probable bug in
fltmgr. I dont have a vista (client) system to hand to see is the same
behavour exists there. I wonder if someone else might be able to check?

Thanks
Lyndon

“Ken Cross” wrote in message news:xxxxx@ntfsd…
> OK, I did indeed miss something obvious. :wink:
>
> But I’m not sure you can ignore tunneling – it may be a factor here.
> I’ve
> found the output of FltGetTunneledName() really did change depending on
> circumstances (the definitions of which are very vague).
>
> So I still ask: Did you check FltGetTunneledName()?
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
> Sent: Friday, March 02, 2007 1:30 PM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Filter manager name cache not correct in presence of
> transactions
>
> Ken
>
> Thanks for your comment.
>
> In post oprtaiton for the IRP_MJ_CREATE of the “CreateFile [OPEN, READ]”
> before the transaction commit the name should of course be the old name.
> This is not the problem.
>
> In post operation for the IRP_MJ_CREATE of the “CreateFile [OPEN, READ]
> NEW”
>
> after the transaction commit the name should of course be the new
> name.
> This is the problem.
>
> In respect of tunnel cache … I am in this test minifilter calling …
>
> FltGetFileNameInformation(CallbackData, FLT_FILE_NAME_NORMALIZED |
> FLT_FILE_NAME_QUERY_DEFAULT, &FileNameInformation);
>
> … in post operation of IRP_MJ_CREATE and IRP_MJ_SET_INFORMATION
> FileRenameInformation, this test minifilter does zero name processing in
> pre-operation, and so there is no need for this test minifilter to meddle
> with tunnel cache.
>
> I hope this makes sense!
>
> Cheers
> Lyndon
>
> “Ken Cross” wrote in message news:xxxxx@ntfsd…
>> Lyndon:
>>
>> Sorry if I’m missing something obvious, but if flag is TRUE, you call
>> CreateFile() before you call CommitTransaction(), so it should still be
>> the old name, shouldn’t it?
>>
>> Also, in the post-Create, did you check FltGetTunneledName()? Not sure
>> if
>> it’s different for transacted operations, but…
>>
>> Ken
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
>> Sent: Friday, March 02, 2007 12:12 PM
>> To: Windows File Systems Devs Interest List
>> Subject: [ntfsd] Filter manager name cache not correct in presence of
>> transactions
>>
>> Gentlefolk
>>
>> I seem to have found a bug in filter manager in WSL Feb CTP. The problem
>> is
>> that the name cache is not correct in the presence of transactions.
>>
>> I have pasted below a test function (user mode) [outlook has messed up
>> indent]. I call this function with filename = “e:\testdir\testfile” and
>> flag
>>
>> as either TRUE or FALSE.
>>
>> If I call with flag TRUE then a call to …
>>
>> FltGetFileNameInformation(CallbackData, FLT_FILE_NAME_NORMALIZED |
>> FLT_FILE_NAME_QUERY_DEFAULT, &FileNameInformation);
>>
>> … in post create for the final create file after the transaction has
>> been
>>
>> commit returns \testdir\testfile which is incorrect instead of
>> \testdir\testfile_new which is correct. If I call the test function with
>> flag FALSE then the correct name is returned from
>> FltGetFileNameInformation.
>>
>> The FltObjects->FileObject->FsContext in all the IRP_MJ_CREATE and
>> IRP_MJ_SET_INFORMATION FileRenameInformation due to test function are all
>> observed to have the same value.
>>
>> I’d be grateful if MSFT could confirm.
>>
>> Cheers
>> Lyndon
>> VOID DoChuckle(WCHAR * filename, BOOL flag)
>>
>> {
>>
>> HANDLE hTransaction;
>>
>> HANDLE hFile;
>>
>> WCHAR filename_new[MAX_PATH];
>>
>> wsprintf(filename_new, L"%s_new", filename);
>>
>> DeleteFile(filename);
>>
>> DeleteFile(filename_new);
>>
>> fwprintf(stdout, L"filename: %s\n", filename);
>>
>> fwprintf(stdout, L"filename_new: %s\n", filename_new);
>>
>> fwprintf(stdout, L"CreateTransaction\n");
>>
>> hTransaction = CreateTransaction(NULL, NULL, 0, 0, 0, 0, NULL);
>>
>> if (hTransaction == INVALID_HANDLE_VALUE)
>>
>> {
>>
>> DWORD dwError = GetLastError();
>>
>> fwprintf(stderr, L"CreateTransaction fails %d\n", dwError);
>>
>> exit(1);
>>
>> }
>>
>> fwprintf(stdout, L"CreateFile [CREATE]\n");
>>
>> hFile = CreateFile(filename,
>>
>> GENERIC_READ | GENERIC_WRITE,
>>
>> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>>
>> NULL,
>>
>> CREATE_NEW,
>>
>> FILE_ATTRIBUTE_NORMAL,
>>
>> NULL);
>>
>> if (hFile == INVALID_HANDLE_VALUE)
>>
>> {
>>
>> DWORD dwError = GetLastError();
>>
>> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>>
>> (void) CloseHandle(hTransaction);
>>
>> exit(1);
>>
>> }
>>
>> (void) CloseHandle(hFile);
>>
>> fwprintf(stdout, L"MoveFileTransacted\n");
>>
>> if (!MoveFileTransacted(filename, filename_new, NULL, NULL,
>> MOVEFILE_REPLACE_EXISTING, hTransaction))
>>
>> {
>>
>> DWORD dwError = GetLastError();
>>
>> fwprintf(stderr, L"MoveFileTransacted fails %d\n", dwError);
>>
>> (void) CloseHandle(hTransaction);
>>
>> exit(1);
>>
>> }
>>
>> if (flag)
>>
>> {
>>
>> fwprintf(stdout, L"CreateFile [OPEN, READ]\n");
>>
>> hFile = CreateFile(filename,
>>
>> GENERIC_READ,
>>
>> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>>
>> NULL,
>>
>> OPEN_EXISTING,
>>
>> FILE_ATTRIBUTE_NORMAL,
>>
>> NULL);
>>
>> if (hFile == INVALID_HANDLE_VALUE)
>>
>> {
>>
>> DWORD dwError = GetLastError();
>>
>> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>>
>> }
>>
>> (void) CloseHandle(hFile);
>>
>> }
>>
>> fwprintf(stdout, L"CommitTransaction\n");
>>
>> if (!CommitTransaction(hTransaction))
>>
>> {
>>
>> DWORD dwError = GetLastError();
>>
>> fwprintf(stderr, L"CommitTransaction fails %d\n", dwError);
>>
>> (void) CloseHandle(hTransaction);
>>
>> exit(1);
>>
>> }
>>
>> fwprintf(stdout, L"CreateFile [OPEN, READ] NEW\n");
>>
>> hFile = CreateFile(filename_new,
>>
>> GENERIC_READ,
>>
>> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>>
>> NULL,
>>
>> OPEN_EXISTING,
>>
>> FILE_ATTRIBUTE_NORMAL,
>>
>> NULL);
>>
>> if (hFile == INVALID_HANDLE_VALUE)
>>
>> {
>>
>> DWORD dwError = GetLastError();
>>
>> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>>
>> }
>>
>> (void) CloseHandle(hFile);
>>
>> (void) CloseHandle(hTransaction);
>>
>> }
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@comcast.net
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

I tried calling FltGetTunneledName now as Ken suggested for some reason :wink:
In these cases it always returned STATUS_SUCCESS with
*RetTunneledFileNameInformation NULL; there was no tunneled name found. This
is much as had been expected.

I’d appreciate is MSFT can confrim the apparent error in fltmgr.

Thanks
Lyndon

“Lyndon J Clarke” wrote in message
news:xxxxx@ntfsd…
> Gentlefolk
>
> I seem to have found a bug in filter manager in WSL Feb CTP. The problem
> is that the name cache is not correct in the presence of transactions.
>
> I have pasted below a test function (user mode) [outlook has messed up
> indent]. I call this function with filename = “e:\testdir\testfile” and
> flag as either TRUE or FALSE.
>
> If I call with flag TRUE then a call to …
>
> FltGetFileNameInformation(CallbackData, FLT_FILE_NAME_NORMALIZED |
> FLT_FILE_NAME_QUERY_DEFAULT, &FileNameInformation);
>
> … in post create for the final create file after the transaction has
> been commit returns \testdir\testfile which is incorrect instead of
> \testdir\testfile_new which is correct. If I call the test function with
> flag FALSE then the correct name is returned from
> FltGetFileNameInformation. The FltObjects->FileObject->FsContext in all
> the IRP_MJ_CREATE and IRP_MJ_SET_INFORMATION FileRenameInformation due to
> test function are all observed to have the same value.
>
> I’d be grateful if MSFT could confirm.
>
> Cheers
> Lyndon
> VOID DoChuckle(WCHAR * filename, BOOL flag)
>
> {
>
> HANDLE hTransaction;
>
> HANDLE hFile;
>
> WCHAR filename_new[MAX_PATH];
>
> wsprintf(filename_new, L"%s_new", filename);
>
> DeleteFile(filename);
>
> DeleteFile(filename_new);
>
> fwprintf(stdout, L"filename: %s\n", filename);
>
> fwprintf(stdout, L"filename_new: %s\n", filename_new);
>
> fwprintf(stdout, L"CreateTransaction\n");
>
> hTransaction = CreateTransaction(NULL, NULL, 0, 0, 0, 0, NULL);
>
> if (hTransaction == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateTransaction fails %d\n", dwError);
>
> exit(1);
>
> }
>
> fwprintf(stdout, L"CreateFile [CREATE]\n");
>
> hFile = CreateFile(filename,
>
> GENERIC_READ | GENERIC_WRITE,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> CREATE_NEW,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> (void) CloseHandle(hFile);
>
> fwprintf(stdout, L"MoveFileTransacted\n");
>
> if (!MoveFileTransacted(filename, filename_new, NULL, NULL,
> MOVEFILE_REPLACE_EXISTING, hTransaction))
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"MoveFileTransacted fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> if (flag)
>
> {
>
> fwprintf(stdout, L"CreateFile [OPEN, READ]\n");
>
> hFile = CreateFile(filename,
>
> GENERIC_READ,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> OPEN_EXISTING,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> }
>
> (void) CloseHandle(hFile);
>
> }
>
> fwprintf(stdout, L"CommitTransaction\n");
>
> if (!CommitTransaction(hTransaction))
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CommitTransaction fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> fwprintf(stdout, L"CreateFile [OPEN, READ] NEW\n");
>
> hFile = CreateFile(filename_new,
>
> GENERIC_READ,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> OPEN_EXISTING,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> }
>
> (void) CloseHandle(hFile);
>
> (void) CloseHandle(hTransaction);
>
> }
>
>
>

Strangeness …

I have configured the WSL test machine for debug using MSCONFIG. I DbgPrint
the FileObject, FileObject->FsContext and the FileNameInformation->Name as
queried just after the name query in post create and post rename (recognize
Ctx sample?). I am watching the DbgPrint output with windbg and/or dbgview.

If I have debugger attached the behaviour as described is observed; the name
returned from the query in post create for the last CreateFile() is
incorrect. If I do not have debugger attached the behaviour is correct. I’m
confident my eyes dont deceive me, but I’ll have a colleague check over the
results next week, just in case.

Cheers
Lyndon

“Lyndon J Clarke” wrote in message
news:xxxxx@ntfsd…
> Gentlefolk
>
> I seem to have found a bug in filter manager in WSL Feb CTP. The problem
> is that the name cache is not correct in the presence of transactions.
>
> I have pasted below a test function (user mode) [outlook has messed up
> indent]. I call this function with filename = “e:\testdir\testfile” and
> flag as either TRUE or FALSE.
>
> If I call with flag TRUE then a call to …
>
> FltGetFileNameInformation(CallbackData, FLT_FILE_NAME_NORMALIZED |
> FLT_FILE_NAME_QUERY_DEFAULT, &FileNameInformation);
>
> … in post create for the final create file after the transaction has
> been commit returns \testdir\testfile which is incorrect instead of
> \testdir\testfile_new which is correct. If I call the test function with
> flag FALSE then the correct name is returned from
> FltGetFileNameInformation. The FltObjects->FileObject->FsContext in all
> the IRP_MJ_CREATE and IRP_MJ_SET_INFORMATION FileRenameInformation due to
> test function are all observed to have the same value.
>
> I’d be grateful if MSFT could confirm.
>
> Cheers
> Lyndon
> VOID DoChuckle(WCHAR * filename, BOOL flag)
>
> {
>
> HANDLE hTransaction;
>
> HANDLE hFile;
>
> WCHAR filename_new[MAX_PATH];
>
> wsprintf(filename_new, L"%s_new", filename);
>
> DeleteFile(filename);
>
> DeleteFile(filename_new);
>
> fwprintf(stdout, L"filename: %s\n", filename);
>
> fwprintf(stdout, L"filename_new: %s\n", filename_new);
>
> fwprintf(stdout, L"CreateTransaction\n");
>
> hTransaction = CreateTransaction(NULL, NULL, 0, 0, 0, 0, NULL);
>
> if (hTransaction == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateTransaction fails %d\n", dwError);
>
> exit(1);
>
> }
>
> fwprintf(stdout, L"CreateFile [CREATE]\n");
>
> hFile = CreateFile(filename,
>
> GENERIC_READ | GENERIC_WRITE,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> CREATE_NEW,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> (void) CloseHandle(hFile);
>
> fwprintf(stdout, L"MoveFileTransacted\n");
>
> if (!MoveFileTransacted(filename, filename_new, NULL, NULL,
> MOVEFILE_REPLACE_EXISTING, hTransaction))
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"MoveFileTransacted fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> if (flag)
>
> {
>
> fwprintf(stdout, L"CreateFile [OPEN, READ]\n");
>
> hFile = CreateFile(filename,
>
> GENERIC_READ,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> OPEN_EXISTING,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> }
>
> (void) CloseHandle(hFile);
>
> }
>
> fwprintf(stdout, L"CommitTransaction\n");
>
> if (!CommitTransaction(hTransaction))
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CommitTransaction fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> fwprintf(stdout, L"CreateFile [OPEN, READ] NEW\n");
>
> hFile = CreateFile(filename_new,
>
> GENERIC_READ,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> OPEN_EXISTING,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> }
>
> (void) CloseHandle(hFile);
>
> (void) CloseHandle(hTransaction);
>
> }
>
>
>

Gentlefolk

My colleague has checked over my tests and results this morning. The
findings now are that the erroneous behaviour (where the name is queried
after the transaaction completes) is erratic however it happens a lot more
often (well, all of the time, in our tests) with a debugger attached. We
also reconfigured the machine not to boot debug (using msconfig) and the
erratic behaviour did not change.

So we are confident that there is this erratic erroneous behaviour, and of
course we are confident this is not in our test code here, where
FltGetFileNameiInformation(…, FLT_FILE_NAME_NORMALIZED |
FLT_FILE_NAME_QUERY_DEFAULT, …)
returns the wrong result.

We did one more test in which we changed the NameOptions
FltGetFileNameiInformation(…, FLT_FILE_NAME_NORMALIZED |
FLT_FILE_NAME_QUERY_FILESYSTEM_ONLY, …)
and this test always returns the correct result.

Now of course we can not assert this is a bug in filter manager as such, but
wherever the root cause it does show up here and, and if we bypass the
filter manager name cache, it does not show up here.

I’d be grateful if MSFT could respond.

Kind regards
Lydnon

“Lyndon J Clarke” wrote in message
news:xxxxx@ntfsd…
> Gentlefolk
>
> I seem to have found a bug in filter manager in WSL Feb CTP. The problem
> is that the name cache is not correct in the presence of transactions.
>
> I have pasted below a test function (user mode) [outlook has messed up
> indent]. I call this function with filename = “e:\testdir\testfile” and
> flag as either TRUE or FALSE.
>
> If I call with flag TRUE then a call to …
>
> FltGetFileNameInformation(CallbackData, FLT_FILE_NAME_NORMALIZED |
> FLT_FILE_NAME_QUERY_DEFAULT, &FileNameInformation);
>
> … in post create for the final create file after the transaction has
> been commit returns \testdir\testfile which is incorrect instead of
> \testdir\testfile_new which is correct. If I call the test function with
> flag FALSE then the correct name is returned from
> FltGetFileNameInformation. The FltObjects->FileObject->FsContext in all
> the IRP_MJ_CREATE and IRP_MJ_SET_INFORMATION FileRenameInformation due to
> test function are all observed to have the same value.
>
> I’d be grateful if MSFT could confirm.
>
> Cheers
> Lyndon
> VOID DoChuckle(WCHAR * filename, BOOL flag)
>
> {
>
> HANDLE hTransaction;
>
> HANDLE hFile;
>
> WCHAR filename_new[MAX_PATH];
>
> wsprintf(filename_new, L"%s_new", filename);
>
> DeleteFile(filename);
>
> DeleteFile(filename_new);
>
> fwprintf(stdout, L"filename: %s\n", filename);
>
> fwprintf(stdout, L"filename_new: %s\n", filename_new);
>
> fwprintf(stdout, L"CreateTransaction\n");
>
> hTransaction = CreateTransaction(NULL, NULL, 0, 0, 0, 0, NULL);
>
> if (hTransaction == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateTransaction fails %d\n", dwError);
>
> exit(1);
>
> }
>
> fwprintf(stdout, L"CreateFile [CREATE]\n");
>
> hFile = CreateFile(filename,
>
> GENERIC_READ | GENERIC_WRITE,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> CREATE_NEW,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> (void) CloseHandle(hFile);
>
> fwprintf(stdout, L"MoveFileTransacted\n");
>
> if (!MoveFileTransacted(filename, filename_new, NULL, NULL,
> MOVEFILE_REPLACE_EXISTING, hTransaction))
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"MoveFileTransacted fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> if (flag)
>
> {
>
> fwprintf(stdout, L"CreateFile [OPEN, READ]\n");
>
> hFile = CreateFile(filename,
>
> GENERIC_READ,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> OPEN_EXISTING,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> }
>
> (void) CloseHandle(hFile);
>
> }
>
> fwprintf(stdout, L"CommitTransaction\n");
>
> if (!CommitTransaction(hTransaction))
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CommitTransaction fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> fwprintf(stdout, L"CreateFile [OPEN, READ] NEW\n");
>
> hFile = CreateFile(filename_new,
>
> GENERIC_READ,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> OPEN_EXISTING,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> }
>
> (void) CloseHandle(hFile);
>
> (void) CloseHandle(hTransaction);
>
> }
>
>
>

Gentlefolk

I have reproduced this with a driver which is trivial mod of Ctx from WDK
6000. If I can find a Vista box I’ll see if the problem is present in Vista
… it is not probable that such a machine is available in our lab however.

Cheers
Lyndon

“Lyndon J Clarke” wrote in message
news:xxxxx@ntfsd…
> Gentlefolk
>
> I seem to have found a bug in filter manager in WSL Feb CTP. The problem
> is that the name cache is not correct in the presence of transactions.
>
> I have pasted below a test function (user mode) [outlook has messed up
> indent]. I call this function with filename = “e:\testdir\testfile” and
> flag as either TRUE or FALSE.
>
> If I call with flag TRUE then a call to …
>
> FltGetFileNameInformation(CallbackData, FLT_FILE_NAME_NORMALIZED |
> FLT_FILE_NAME_QUERY_DEFAULT, &FileNameInformation);
>
> … in post create for the final create file after the transaction has
> been commit returns \testdir\testfile which is incorrect instead of
> \testdir\testfile_new which is correct. If I call the test function with
> flag FALSE then the correct name is returned from
> FltGetFileNameInformation. The FltObjects->FileObject->FsContext in all
> the IRP_MJ_CREATE and IRP_MJ_SET_INFORMATION FileRenameInformation due to
> test function are all observed to have the same value.
>
> I’d be grateful if MSFT could confirm.
>
> Cheers
> Lyndon
> VOID DoChuckle(WCHAR * filename, BOOL flag)
>
> {
>
> HANDLE hTransaction;
>
> HANDLE hFile;
>
> WCHAR filename_new[MAX_PATH];
>
> wsprintf(filename_new, L"%s_new", filename);
>
> DeleteFile(filename);
>
> DeleteFile(filename_new);
>
> fwprintf(stdout, L"filename: %s\n", filename);
>
> fwprintf(stdout, L"filename_new: %s\n", filename_new);
>
> fwprintf(stdout, L"CreateTransaction\n");
>
> hTransaction = CreateTransaction(NULL, NULL, 0, 0, 0, 0, NULL);
>
> if (hTransaction == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateTransaction fails %d\n", dwError);
>
> exit(1);
>
> }
>
> fwprintf(stdout, L"CreateFile [CREATE]\n");
>
> hFile = CreateFile(filename,
>
> GENERIC_READ | GENERIC_WRITE,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> CREATE_NEW,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> (void) CloseHandle(hFile);
>
> fwprintf(stdout, L"MoveFileTransacted\n");
>
> if (!MoveFileTransacted(filename, filename_new, NULL, NULL,
> MOVEFILE_REPLACE_EXISTING, hTransaction))
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"MoveFileTransacted fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> if (flag)
>
> {
>
> fwprintf(stdout, L"CreateFile [OPEN, READ]\n");
>
> hFile = CreateFile(filename,
>
> GENERIC_READ,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> OPEN_EXISTING,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> }
>
> (void) CloseHandle(hFile);
>
> }
>
> fwprintf(stdout, L"CommitTransaction\n");
>
> if (!CommitTransaction(hTransaction))
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CommitTransaction fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> fwprintf(stdout, L"CreateFile [OPEN, READ] NEW\n");
>
> hFile = CreateFile(filename_new,
>
> GENERIC_READ,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> OPEN_EXISTING,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> }
>
> (void) CloseHandle(hFile);
>
> (void) CloseHandle(hTransaction);
>
> }
>
>
>

Gentlefolk

I have been able to cofnirm this problem on RTM Vista; you have been warned
:wink:

Kind regards
Lyndon

“Lyndon J Clarke” wrote in message
news:xxxxx@ntfsd…
> Gentlefolk
>
> I seem to have found a bug in filter manager in WSL Feb CTP. The problem
> is that the name cache is not correct in the presence of transactions.
>
> I have pasted below a test function (user mode) [outlook has messed up
> indent]. I call this function with filename = “e:\testdir\testfile” and
> flag as either TRUE or FALSE.
>
> If I call with flag TRUE then a call to …
>
> FltGetFileNameInformation(CallbackData, FLT_FILE_NAME_NORMALIZED |
> FLT_FILE_NAME_QUERY_DEFAULT, &FileNameInformation);
>
> … in post create for the final create file after the transaction has
> been commit returns \testdir\testfile which is incorrect instead of
> \testdir\testfile_new which is correct. If I call the test function with
> flag FALSE then the correct name is returned from
> FltGetFileNameInformation. The FltObjects->FileObject->FsContext in all
> the IRP_MJ_CREATE and IRP_MJ_SET_INFORMATION FileRenameInformation due to
> test function are all observed to have the same value.
>
> I’d be grateful if MSFT could confirm.
>
> Cheers
> Lyndon
> VOID DoChuckle(WCHAR * filename, BOOL flag)
>
> {
>
> HANDLE hTransaction;
>
> HANDLE hFile;
>
> WCHAR filename_new[MAX_PATH];
>
> wsprintf(filename_new, L"%s_new", filename);
>
> DeleteFile(filename);
>
> DeleteFile(filename_new);
>
> fwprintf(stdout, L"filename: %s\n", filename);
>
> fwprintf(stdout, L"filename_new: %s\n", filename_new);
>
> fwprintf(stdout, L"CreateTransaction\n");
>
> hTransaction = CreateTransaction(NULL, NULL, 0, 0, 0, 0, NULL);
>
> if (hTransaction == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateTransaction fails %d\n", dwError);
>
> exit(1);
>
> }
>
> fwprintf(stdout, L"CreateFile [CREATE]\n");
>
> hFile = CreateFile(filename,
>
> GENERIC_READ | GENERIC_WRITE,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> CREATE_NEW,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> (void) CloseHandle(hFile);
>
> fwprintf(stdout, L"MoveFileTransacted\n");
>
> if (!MoveFileTransacted(filename, filename_new, NULL, NULL,
> MOVEFILE_REPLACE_EXISTING, hTransaction))
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"MoveFileTransacted fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> if (flag)
>
> {
>
> fwprintf(stdout, L"CreateFile [OPEN, READ]\n");
>
> hFile = CreateFile(filename,
>
> GENERIC_READ,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> OPEN_EXISTING,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> }
>
> (void) CloseHandle(hFile);
>
> }
>
> fwprintf(stdout, L"CommitTransaction\n");
>
> if (!CommitTransaction(hTransaction))
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CommitTransaction fails %d\n", dwError);
>
> (void) CloseHandle(hTransaction);
>
> exit(1);
>
> }
>
> fwprintf(stdout, L"CreateFile [OPEN, READ] NEW\n");
>
> hFile = CreateFile(filename_new,
>
> GENERIC_READ,
>
> FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
>
> NULL,
>
> OPEN_EXISTING,
>
> FILE_ATTRIBUTE_NORMAL,
>
> NULL);
>
> if (hFile == INVALID_HANDLE_VALUE)
>
> {
>
> DWORD dwError = GetLastError();
>
> fwprintf(stderr, L"CreateFile fails %d\n", dwError);
>
> }
>
> (void) CloseHandle(hFile);
>
> (void) CloseHandle(hTransaction);
>
> }
>
>
>