My filter sees and processes renames as a result of IRP_MJ_SET_INFORMATION
packets. When they occur, I latch the target name (fully qualified) from
the FILE_RENAME_INFORMATION passed in Irp->AssociatedIrp.SystemBuffer.
The source file name I had from back at open time and I copy both to a
structure that gets passed out to my Ring 3 helper. Problem is that I’m
seeing “extra” characters both at the head and tail of the rename target
file.
-
At the head I see an extraneous "??" in front of the filename (e.g.
“C:\targetfile.ext”).
-
At the tail there are sometimes several extra chars, usually beginning
with a ‘?’.
I think there is probably a system reason for case 1, but I’m concerned
about case 2. I was using wcscpy() to copy the WCHAR string from the
FILE_RENAME_INFORMATION structure. I’ve taken to memsetting my target
buffer to zero, then using wcsncpy() instead, copying only the number of
chars indicated by the FileNameLength member of the
FILE_RENAME_INFORMATION structure. Is that FileName string not a nicely
terminated WCHAR string? Am I overlooking something obvious?
TIA,
Bill
The string in FILE_RENAME_INFORMATION is not necessarily null-terminated
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill
Sent: Tuesday, March 04, 2003 11:44 AM
To: File Systems Developers
Subject: [ntfsd] FILE_RENAME_INFORMATION
My filter sees and processes renames as a result of
IRP_MJ_SET_INFORMATION packets. When they occur, I latch the
target name (fully qualified) from the
FILE_RENAME_INFORMATION passed in Irp->AssociatedIrp.SystemBuffer.
The source file name I had from back at open time and I copy
both to a structure that gets passed out to my Ring 3 helper.
Problem is that I’m seeing “extra” characters both at the
head and tail of the rename target file.
-
At the head I see an extraneous "??" in front of the
filename (e.g. “C:\targetfile.ext”).
-
At the tail there are sometimes several extra chars,
usually beginning with a ‘?’.
I think there is probably a system reason for case 1, but I’m
concerned about case 2. I was using wcscpy() to copy the
WCHAR string from the FILE_RENAME_INFORMATION structure.
I’ve taken to memsetting my target buffer to zero, then using
wcsncpy() instead, copying only the number of chars indicated
by the FileNameLength member of the FILE_RENAME_INFORMATION
structure. Is that FileName string not a nicely terminated
WCHAR string? Am I overlooking something obvious?
TIA,
Bill
You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
UNICODE_STRING is not NULL terminated - most of the time. While
RtlUnicodeStringToAnsiSize and RtlAnsiStringToUnicodeSize will return the size
WITH the NULL terminator character, the strings are rarely NULL terminated.
Case 1 is common, and has to be addressed - case 2 is result of using NULL
terminated string analogy instead of counted string one.
Bill wrote:
My filter sees and processes renames as a result of IRP_MJ_SET_INFORMATION
packets. When they occur, I latch the target name (fully qualified) from
the FILE_RENAME_INFORMATION passed in Irp->AssociatedIrp.SystemBuffer.
The source file name I had from back at open time and I copy both to a
structure that gets passed out to my Ring 3 helper. Problem is that I’m
seeing “extra” characters both at the head and tail of the rename target
file.
-
At the head I see an extraneous "??" in front of the filename (e.g.
“C:\targetfile.ext”).
-
At the tail there are sometimes several extra chars, usually beginning
with a ‘?’.
I think there is probably a system reason for case 1, but I’m concerned
about case 2. I was using wcscpy() to copy the WCHAR string from the
FILE_RENAME_INFORMATION structure. I’ve taken to memsetting my target
buffer to zero, then using wcsncpy() instead, copying only the number of
chars indicated by the FileNameLength member of the
FILE_RENAME_INFORMATION structure. Is that FileName string not a nicely
terminated WCHAR string? Am I overlooking something obvious?
TIA,
Bill
You are currently subscribed to ntfsd as: xxxxx@alfasp.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
–
Kind regards, Dejan M. www.alfasp.com
E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.
> UNICODE_STRING is not NULL terminated - most of the time. While
RtlUnicodeStringToAnsiSize and RtlAnsiStringToUnicodeSize will return the size
WITH the NULL terminator character, the strings are rarely NULL terminated.
Case 1 is common, and has to be addressed - case 2 is result of using NULL
terminated string analogy instead of counted string one.
Thanks, Dejan (and Nick), for clearly stating what I just determined
heuristically. Using the indicated length resolves the string tail issue
I had (we already know how to handle the symbolic link chars at the head
end). I guess my first clue should have been that the structure comes
with an counted length! 
I’m still waiting on my IFS kit… Would I have expected to see this
documented there? Or, does simple experience dictate that the existence
of a counted length IMPLIES that the string is NOT null terminated?
There is nothing implying that it is NULL terminated, otherwise, what is the use
of the length field. It is NOT documented.
This seems normal for me, as I come from Pascal background, where NULL
terminated strings are similar to DLL hell:-)
One more thing you should note for the rename. While ??\ is the most common
way, it is possible to get \DosDevices\ instead of it, or not to have any header at
all. I have code that gets the destination for the rename, which about 10 times
larger than the retrieval and creation of the file name during Create:-)
Bill wrote:
Thanks, Dejan (and Nick), for clearly stating what I just determined
heuristically. Using the indicated length resolves the string tail issue
I had (we already know how to handle the symbolic link chars at the head end). I
guess my first clue should have been that the structure comes with an counted
length!
I’m still waiting on my IFS kit… Would I have expected to see this
documented there? Or, does simple experience dictate that the existence of a
counted length IMPLIES that the string is NOT null terminated?
–
Kind regards, Dejan M. www.alfasp.com
E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.
The fact that there is a length field is a clue, to be sure, but this is
clearly not a typical UNICODE_STRING, either. If so, not only would it
have a length, but a maximum length and a pointer to the buffer as well.
Seems like this particular struct (FILE_RENAME_INFORMATION) was some kind
of orphan.
Despite my festuch with the NULL termination (or lack thereof) I’m aware
of the possibilities for the destination file name (though I’d sure like
to take a look at your code, hint, hint).
Bill
There is nothing implying that it is NULL terminated, otherwise, what is the use
of the length field. It is NOT documented.
This seems normal for me, as I come from Pascal background, where NULL
terminated strings are similar to DLL hell:-)
One more thing you should note for the rename. While ??\ is the most common
way, it is possible to get \DosDevices\ instead of it, or not to have any header at
all. I have code that gets the destination for the rename, which about 10 times
larger than the retrieval and creation of the file name during Create:-)
> documented there? Or, does simple experience dictate that the
existence
of a counted length IMPLIES that the string is NOT null terminated?
You cannot rely on it, since the other code does not impose such a
guarantee.
For instance, some code uses one UNICODE_STRING as a substring of
another longer one. The substring is not zero-terminated for sure.
Max
> The fact that there is a length field is a clue, to be sure, but this is
clearly not a typical UNICODE_STRING, either. If so, not only would it have a length,
but a maximum length and a pointer to the buffer as well. Seems like this particular
struct (FILE_RENAME_INFORMATION) was some kind of orphan.
MaximumLength is there for conversion routines, which need to know how much data
can fit - while they need not fill all the data positions.
Despite my festuch with the NULL termination (or lack thereof) I’m aware of the
possibilities for the destination file name (though I’d sure like to take a look at
your code, hint, hint).
(Hint, hint)
There’s an NT Insider article on which I based most of it - while still doing
some extra twisting since the article is wrong about a few places, and does not tell
about a few cases (like the ??\ one)
–
Kind regards, Dejan M. www.alfasp.com
E-mail: xxxxx@alfasp.com
Alfa Transparent File Encryptor - Transparent file encryption services.
Alfa File Protector - File protection and hiding library for Win32 developers.
Alfa File Monitor - File monitoring library for Win32 developers.