Curt,
From an implementation standpoint, a counted byte string is
indistinguishable from a counted unicode string. That is because the Length
and MaximumLength fields (for both STRING and UNICODE_STRING) indicate the
number of BYTES.
Thus, it is operationally impossible to distinguish the string “\0F\0o\0o”
and the wide character string L"Foo" (assuming each is counted based upon
the number of bytes.) So, that would indicate it is more likely the case
that we have a “doesn’t matter”.
This is more an historical oddity than anything sinister or important - the
decision to go with 16 bit unicode in the file systems interface was clearly
one that was not made “at the beginning” and instead evolved over time.
Practically speaking there is only one place where you must handle 8-bit
characters: the names of extended attributes.
Thus, I’d argue that both ntifs.h and Windows 2000 are correct and
consistent with respect to one another.
Regards,
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com http:
-----Original Message-----
From: xxxxx@omnishift.com [mailto:xxxxx@omnishift.com]
Sent: Thursday, June 22, 2000 12:56 AM
To: File Systems Developers
Subject: [ntfsd] Redux: IO_STACK_LOCATION.Parameters.QueryDirectory struct
members
Hi:
In late May, xxxxx@Satyam.com asked about the nature of the structure
members of the QueryDirectory Parameters structure in the IO stack location.
(This isn’t documented in the DDK headers, only in the IFS header.) It
doesn’t appear to me that this was ever answered.
Rajeev Nagar’s book shows the FileName parameter as a “PSTRING” (counted
single-byte string), and, now that I have the W2000 IFS kit, ntifs.h shows
the same type.
However, on W2000, I’ve observed empirically that the FileName is a
PUNICODE_STRING, and using it like this has been working for me.
So: Is the ntifs.h file wrong, at least for W2000?
Thanks,
Curt</http:>