Rename/Link: Who frees the new InfoBuffer?

NTFSD
1

In IRP_MJ_SET_INFORMATION (rename and link), I allocate a new
FILE_RENAME_INFORMATION struct in which I adjust the destination name:

new_destination->ReplaceIfExists = rename->ReplaceIfExists;
new_destination->RootDirectory = rename->RootDirectory;
new_destination->FileNameLength = destination_redirectName.Length;
RtlCopyMemory(&new_destination->FileName[0],
destination_redirectName.Buffer,
destination_redirectName.Length);
Data->Iopb->Parameters.SetFileInformation.InfoBuffer = new_destination;

FltSetCallbackDataDirty(Data);

Do I need to free the old InfoBuffer? (I guess not, I guess that higher
filters will still see it in their post-op callback)

Do I need to free the new InfoBuffer (new_destination) in my post-op, or
will FltManager have noticed what I changed during
FltSetCallbackDataDirty and free it for me?

Sam

2

its your memory, no other driver or application knows/care about it, so you have to free it, simple.

Filter manager does not bother about this, In fact in your post op it will actually pass you the original buffer, not the modified buffer. So in case of certain operations like read, directory control, its your responsibility to copy it to the original buffer.

Thanks,
Aditya

3

Register a post routine and free your buffer in that routine. Be careful
that the callback data will contain the original buffer in the post routine
and not the one that you have stuffed in. So, you need to pass it via the
completion context.

Regards,
Ayush Gupta
AI Consulting

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Sam Liddicott
Sent: Friday, November 06, 2009 5:57 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Rename/Link: Who frees the new InfoBuffer?

In IRP_MJ_SET_INFORMATION (rename and link), I allocate a new
FILE_RENAME_INFORMATION struct in which I adjust the destination name:

new_destination->ReplaceIfExists = rename->ReplaceIfExists;
new_destination->RootDirectory = rename->RootDirectory;
new_destination->FileNameLength = destination_redirectName.Length;
RtlCopyMemory(&new_destination->FileName[0],
destination_redirectName.Buffer,
destination_redirectName.Length);
Data->Iopb->Parameters.SetFileInformation.InfoBuffer = new_destination;

FltSetCallbackDataDirty(Data);

Do I need to free the old InfoBuffer? (I guess not, I guess that higher
filters will still see it in their post-op callback)

Do I need to free the new InfoBuffer (new_destination) in my post-op, or
will FltManager have noticed what I changed during
FltSetCallbackDataDirty and free it for me?

Sam

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

4

Sam,

Rather than modifying the original request, you could just turn around and issue your own SetInformation with FltSetInformationFile. We are using that approach in some new sample code. Don’t forget to set the IoStatus.Status in the original request if your call to FltSetInformationFile fails.

Scott
This posting is provided “AS IS” with no warranties, and confers no rights.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Ayush Gupta
Sent: Friday, November 06, 2009 5:09 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Rename/Link: Who frees the new InfoBuffer?

Register a post routine and free your buffer in that routine. Be careful
that the callback data will contain the original buffer in the post routine
and not the one that you have stuffed in. So, you need to pass it via the
completion context.

Regards,
Ayush Gupta
AI Consulting

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Sam Liddicott
Sent: Friday, November 06, 2009 5:57 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Rename/Link: Who frees the new InfoBuffer?

In IRP_MJ_SET_INFORMATION (rename and link), I allocate a new
FILE_RENAME_INFORMATION struct in which I adjust the destination name:

new_destination->ReplaceIfExists = rename->ReplaceIfExists;
new_destination->RootDirectory = rename->RootDirectory;
new_destination->FileNameLength = destination_redirectName.Length;
RtlCopyMemory(&new_destination->FileName[0],
destination_redirectName.Buffer,
destination_redirectName.Length);
Data->Iopb->Parameters.SetFileInformation.InfoBuffer = new_destination;

FltSetCallbackDataDirty(Data);

Do I need to free the old InfoBuffer? (I guess not, I guess that higher
filters will still see it in their post-op callback)

Do I need to free the new InfoBuffer (new_destination) in my post-op, or
will FltManager have noticed what I changed during
FltSetCallbackDataDirty and free it for me?

Sam

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

5

Thanks Scott, that’s a good thought.

Also thanks to Ayush and Adi.

Sam

-----Original Message-----
From: Scott Brender
Sent: 06 November 2009 18:26
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Rename/Link: Who frees the new InfoBuffer?

Sam,

Rather than modifying the original request, you could just turn around and issue your own SetInformation with FltSetInformationFile. We are using that approach in some new sample code. Don’t forget to set the IoStatus.Status in the original request if your call to FltSetInformationFile fails.

Scott
This posting is provided “AS IS” with no warranties, and confers no rights.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Ayush Gupta
Sent: Friday, November 06, 2009 5:09 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Rename/Link: Who frees the new InfoBuffer?

Register a post routine and free your buffer in that routine. Be careful
that the callback data will contain the original buffer in the post routine
and not the one that you have stuffed in. So, you need to pass it via the
completion context.

Regards,
Ayush Gupta
AI Consulting

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Sam Liddicott
Sent: Friday, November 06, 2009 5:57 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Rename/Link: Who frees the new InfoBuffer?

In IRP_MJ_SET_INFORMATION (rename and link), I allocate a new
FILE_RENAME_INFORMATION struct in which I adjust the destination name:

new_destination->ReplaceIfExists = rename->ReplaceIfExists;
new_destination->RootDirectory = rename->RootDirectory;
new_destination->FileNameLength = destination_redirectName.Length;
RtlCopyMemory(&new_destination->FileName[0],
destination_redirectName.Buffer,
destination_redirectName.Length);
Data->Iopb->Parameters.SetFileInformation.InfoBuffer = new_destination;

FltSetCallbackDataDirty(Data);

Do I need to free the old InfoBuffer? (I guess not, I guess that higher
filters will still see it in their post-op callback)

Do I need to free the new InfoBuffer (new_destination) in my post-op, or
will FltManager have noticed what I changed during
FltSetCallbackDataDirty and free it for me?

Sam

—
NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

—
NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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

—
NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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