GetVolumePathNamesForVolumeName - invalid name

OSR_Community_User · April 11, 2006, 6:57pm

Hello,

I am having trouble getting my call to GetVolumePathNamesForVolumeName to
work. The code is attached below. I caught the vol guid that I epxected and
hardcoded it into the call, but it still fails with ‘ERROR_INVALID_NAME’.
The vol guid looks like this:
??\Volume{db7730a0-3f31-11da-acbe-806d6172696f}

Is this the wrong format? Or am I doing another mistake with the call?

Here is the code:

(WCHAR volGuid[256] is passed in - I know I need to change this to
WCHAR*, but have some trouble with this passing it up correctly fromkernel
to user))

DWORD bufSize = 128;
DWORD reqBufSize=0;
LPWSTR volPathNames = NULL;

volPathNames = (LPWSTR) malloc( bufSize);

BOOL res = GetVolumePathNamesForVolumeName( (LPTSTR) volGuid,
volPathNames,
bufSize,
&reqBufSize );

(the actual code does additional checking to make sure bufSize is big enough
and sets it to reqbuf if it’s not)

Thanks, bjorn

PS:
I tried a simialr approach to call GetVolumePathName with “.” as file name
input, which works fine.

OSR_Community_User · April 11, 2006, 7:59pm

You are probably mixing up ansi and Unicode.

OSR_Community_User · April 12, 2006, 10:42am

I believe for that routine you need the prefix \?, not ??.

Dan.

Hello,

I am having trouble getting my call to GetVolumePathNamesForVolumeName to
work. The code is attached below. I caught the vol guid that I epxected and
hardcoded it into the call, but it still fails with ‘ERROR_INVALID_NAME’.
The vol guid looks like this:
??\Volume{db7730a0-3f31-11da-acbe-806d6172696f}

Is this the wrong format? Or am I doing another mistake with the call?

OSR_Community_User · April 12, 2006, 1:04pm

“Dan Kyler” wrote in message news:xxxxx@ntfsd…
>I believe for that routine you need the prefix \?, not ??.

I have now tried all possible combos (e.g. one, two or no ?, no trailing
backslash etc). I either get ‘ERROR_INVALID_NAME’ or
ERROR_INVALID_PARAMETER.

thanks, bjorn

>
> - Dan.
>
> -------------------
> Hello,
>
> I am having trouble getting my call to GetVolumePathNamesForVolumeName to
> work. The code is attached below. I caught the vol guid that I epxected
> and
> hardcoded it into the call, but it still fails with ‘ERROR_INVALID_NAME’.
> The vol guid looks like this:
> ??\Volume{db7730a0-3f31-11da-acbe-806d6172696f}
>
> Is this the wrong format? Or am I doing another mistake with the call?
>
>

OSR_Community_User · April 12, 2006, 1:21pm

“Satya Das” wrote in message news:xxxxx@ntfsd…
You are probably mixing up ansi and Unicode.

I defined UNICODE and _UNICODE in my build file. I pass in a WCHAR to hold
the volume path names and pass in unicode as vol Guid (hardcoded, with L in
front).

The only thing I can think of: The DWORD and PDWORD for length and req
length are said to be TCHAR. I initialized the DWORD size to 128 - maybe
that is what’s wrong with it?

Thanks, bjorn

OSR_Community_User · April 12, 2006, 3:25pm

BufSize is invalid … 128 bytes == 64 WCHARs … Note that TCHAR in UNICDOE is defined as WCHAR.

-Ilya.

-------------- Original message --------------
From: “bjorn haake”

>
> “Satya Das” wrote in message news:xxxxx@ntfsd…
> You are probably mixing up ansi and Unicode.
>
> I defined UNICODE and _UNICODE in my build file. I pass in a WCHAR to hold
> the volume path names and pass in unicode as vol Guid (hardcoded, with L in
> front).
>
> The only thing I can think of: The DWORD and PDWORD for length and req
> length are said to be TCHAR. I initialized the DWORD size to 128 - maybe
> that is what’s wrong with it?
>
> Thanks, bjorn
>
>
>
> —
> 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

OSR_Community_User · April 12, 2006, 5:04pm

wrote in message news:xxxxx@ntfsd…
>BufSize is invalid … 128 bytes == 64 WCHARs … Note that TCHAR in
>UNICDOE >is defined as WCHAR.

Hi Ilya,

thanks for the reply - I may just have some trouble understanding it. I am
under the impression that I can call GetVolumePathNamesForVolumeName with a
buffer size of 0 and the required Buf Size (last param) will tell me how
much I need. So even if 128 is really only 64 (and therefore too small) I
would expect the error 'ERROR_MORE_DATA to come back. Or did I miss
something else in your response?

Thanks, bjorn

-------------- Original message --------------
From: “bjorn haake”

>
> “Satya Das” wrote in message news:xxxxx@ntfsd…
> You are probably mixing up ansi and Unicode.
>
> I defined UNICODE and _UNICODE in my build file. I pass in a WCHAR to
> hold
> the volume path names and pass in unicode as vol Guid (hardcoded, with L
> in
> front).
>
> The only thing I can think of: The DWORD and PDWORD for length and req
> length are said to be TCHAR. I initialized the DWORD size to 128 - maybe
> that is what’s wrong with it?
>
> Thanks, bjorn
>
>
>
> —
> 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

OSR_Community_User · April 12, 2006, 5:54pm

The point is that you *told* GetVolumePathNamesForVolumeName that your
buffer was 128 TCHARs when it was in fact only 64 TCHARs (128 bytes). 128
TCHARs may be big enough, but would cause a buffer overflow. Nasty.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of bjorn haake
Sent: Wednesday, April 12, 2006 5:03 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Re:GetVolumePathNamesForVolumeName - invalid name

wrote in message news:xxxxx@ntfsd…
>BufSize is invalid … 128 bytes == 64 WCHARs … Note that TCHAR in
>UNICDOE >is defined as WCHAR.

Hi Ilya,

thanks for the reply - I may just have some trouble understanding it. I am
under the impression that I can call GetVolumePathNamesForVolumeName with a
buffer size of 0 and the required Buf Size (last param) will tell me how
much I need. So even if 128 is really only 64 (and therefore too small) I
would expect the error 'ERROR_MORE_DATA to come back. Or did I miss
something else in your response?

Thanks, bjorn

-------------- Original message --------------
From: “bjorn haake”

>
> “Satya Das” wrote in message news:xxxxx@ntfsd…
> You are probably mixing up ansi and Unicode.
>
> I defined UNICODE and _UNICODE in my build file. I pass in a WCHAR to
> hold
> the volume path names and pass in unicode as vol Guid (hardcoded, with L
> in
> front).
>
> The only thing I can think of: The DWORD and PDWORD for length and req
> length are said to be TCHAR. I initialized the DWORD size to 128 - maybe
> that is what’s wrong with it?
>
> Thanks, bjorn
>
>
>
> —
> 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

OSR_Community_User · April 12, 2006, 7:42pm

“Dan Kyler” wrote in message news:xxxxx@ntfsd…
>I believe for that routine you need the prefix \?, not ??.

Dan,

thanks - you were correct. I did of course do a mistake when I put it in
hardcoded - I put in two ‘\’ w/o realizing that one is an escape…
Also, the back slash at the end is mandatory as well. Phew.

(So the hardcoded string looks like this:

L"\\?\Volume{db7730a0-3f31-11da-acbe-806d6172696f}\"

Thanks again, bjorn
>
> - Dan.
>
> -------------------
> Hello,
>
> I am having trouble getting my call to GetVolumePathNamesForVolumeName to
> work. The code is attached below. I caught the vol guid that I epxected
> and
> hardcoded it into the call, but it still fails with ‘ERROR_INVALID_NAME’.
> The vol guid looks like this:
> ??\Volume{db7730a0-3f31-11da-acbe-806d6172696f}
>
> Is this the wrong format? Or am I doing another mistake with the call?
>
>