Discussion:
WMI and MAX_PATH limitation?
(too old to reply)
Gerry Hickman
2008-10-09 12:15:02 UTC
Permalink
Hi,

If I obtain a collection of CIM_DataFile objects from a Win32_Directory
object containing 4 files, I'll usually get a count of 4, but if the path of
any file is longer than 256 characters, I get an incorrect count such as 3.
This is on Windows Server 2003 R2 x86 with all service packs applied.

Since WMI is based on COM, which is Unicode aware, I don't expect to see
this kind of problem. Is there a way to force WMI to work in Unicode?

My program is designed to run file checksums on multiple servers; I thought
WMI would be a good choice for this but it's giving me inaccurate data!
--
Gerry Hickman
London (UK)
Jialiang Ge [MSFT]
2008-10-10 07:13:31 UTC
Permalink
Good morning Gerry. Welcome back our support service.

You question is about the MAX_PATH limitation (260 characters) in WMI
CIM_DataFile objects. I looked into the WMI provider and verified that WMI
does not support file names greater than 260. If we encounter such a file,
WMI stops the enumeration. I have also verified that the Windows Scripting
host Folder object does not support them. If we try to get the files or
subfolders collection we get a file not found error which prevents the
population of the collection. I can understand the impact of this
limitation on your solution. May I suggest the following workaround?

==== WORKAROUND ====
The Win32 APIs do support filenames greater than 260 characters if you
follow the documentation here which describes using a path similar to
(\\?\E:\<path>) with the Unicode versions of the APIs:
http://msdn.microsoft.com/en-us/library/aa365247.aspx

So the workaround I see is to use the APIs to recursively enumerate the
file system including filenames greater than 260 characters. Here is an
example that we can start with.
http://vbnet.mvps.org/index.html?code/fileapi/folderenumadvanced.htm
It demonstrates the ANSI version of enumerating the folder. We need to
change it to the Unicode version. For example, FindFirstFileA ->
FindFirstFileW

The next step is to integrate the above function into your current solution:
1. If your solution is a vbscript file
There are no scriptable components which support filename greater than 260
characters, and vbscript cannot directly call Windows API, however, we
could make the API calls through a COM wrapper and call the COM object from
the script.
2. If your solution is a program written in VC/VB or other programming
languages, we can call the Windows APIs directly in them.

Please let me know whether you agree with this workaround or not. If more
examples or illustrations are needed, don't hesitate to tell me. In
addition, I will convey the problem of supporing file name larger than
MAX_PATH in WMI CIM_DataFile objects to the person responsbile for the WMI
provider. Thanks.

Best Regards,
Jialiang Ge (***@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
***@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://support.microsoft.com/select/default.aspx?target=assistance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Gerry Hickman
2008-10-10 09:14:55 UTC
Permalink
Dear Jialiang,

Thank you for looking into this problem so quickly and providing
verification.

I'm not pleased with the work-around suggested because it effectively means
WMI can not be used for file names greater than 260 characters, and in
modern business this is very common. WMI is supposed to help us carry out
common tasks without using the Windows API. The WMI provider should be
designed to call the latest Microsoft APIs.

A different problem is that I need to program to work against multiple
remote servers. I can't call the Windows API from within the remote WMI
session.

Some people may say "why not just use UNC", but the whole point of WMI is
that you are working in a local context, but on a remote machine. This is
very different to using a network redirector and SMB, and you would also
lose the link between the client and server processes.
--
Gerry Hickman
London (UK)
Post by Jialiang Ge [MSFT]
Good morning Gerry. Welcome back our support service.
You question is about the MAX_PATH limitation (260 characters) in WMI
CIM_DataFile objects. I looked into the WMI provider and verified that WMI
does not support file names greater than 260. If we encounter such a file,
WMI stops the enumeration. I have also verified that the Windows Scripting
host Folder object does not support them. If we try to get the files or
subfolders collection we get a file not found error which prevents the
population of the collection. I can understand the impact of this
limitation on your solution. May I suggest the following workaround?
==== WORKAROUND ====
The Win32 APIs do support filenames greater than 260 characters if you
follow the documentation here which describes using a path similar to
http://msdn.microsoft.com/en-us/library/aa365247.aspx
So the workaround I see is to use the APIs to recursively enumerate the
file system including filenames greater than 260 characters. Here is an
example that we can start with.
http://vbnet.mvps.org/index.html?code/fileapi/folderenumadvanced.htm
It demonstrates the ANSI version of enumerating the folder. We need to
change it to the Unicode version. For example, FindFirstFileA ->
FindFirstFileW
1. If your solution is a vbscript file
There are no scriptable components which support filename greater than 260
characters, and vbscript cannot directly call Windows API, however, we
could make the API calls through a COM wrapper and call the COM object from
the script.
2. If your solution is a program written in VC/VB or other programming
languages, we can call the Windows APIs directly in them.
Please let me know whether you agree with this workaround or not. If more
examples or illustrations are needed, don't hesitate to tell me. In
addition, I will convey the problem of supporing file name larger than
MAX_PATH in WMI CIM_DataFile objects to the person responsbile for the WMI
provider. Thanks.
Best Regards,
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://support.microsoft.com/select/default.aspx?target=assistance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Jialiang Ge [MSFT]
2008-10-10 09:40:11 UTC
Permalink
Hello Gerry,

I understand your concerns. I'm performing further researches for
workarounds from WMI's perspective. In the meantime, I will forward the
question to the product group and try to bring back their suggestions.

Regards,
Jialiang Ge (***@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
***@microsoft.com.

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================
Jialiang Ge [MSFT]
2008-10-14 05:25:04 UTC
Permalink
Dear Gerry,

I am still researching this post "WMI and MAX_PATH limitation" in the WMI
newsgroup. I searched our support history of Microsoft Customer Support
Service (CSS) department for similar cases, and find that the workarounds
for this MAX_PATH limit are majorly the following three points:

1. Use native Windows APIs instead of WMI.
This point was mentioned in my initial reply, and I understand your concern
that it does not fit your business environment.

2. Write a small application to scan the disk and move away or rename all
the directories with long path (> MAX_PATH).

3. Use "net use" command to access these long file path through a local
redirection.
For example, suppose we need to list the sub folders under the long dir:
\\[computer name]\D$\[long dir]\, we may use "net use" command to create a
redirection:
net use x: \\[computer name]\D$\[long dir]\ and then access the
sub-folder by enumerating the shorter name: x:\.

Based on my experience, this MAX_PATH limit not only appears in WMI, but
also exists in Windows Explorer and cmd.exe command prompt:
http://support.microsoft.com/kb/177665/en-us
http://support.microsoft.com/kb/205345/en-us
The workaround of these problems documented in the KB article are within
the above three points.

Gerry, I totally understand the business impact of this limit on your
product environment and I sincerely want to help you out, however, based on
my research, it is indeed difficult to find out a "perfect" solution at the
moment. Please kindly review my above three suggestions to see whether they
have any chance to help you work around the problem. I also assure you that
the product group will know your concerns and this post will be achieved
for their future references.

Sincerely and best regards,
Jialiang Ge (***@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
***@microsoft.com.

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================
Gerry Hickman
2008-10-14 13:38:01 UTC
Permalink
Dear Jialiang Ge,

First the non-technical answer.

The workarounds suggested to this WMI problem are essentially saying "don't
use WMI", which is not a WMI solution. It's a bit like someone saying they
have a problem in Windows and the solution is "Go use Linux". It may be a
workaround, but it's not addressing the problem.

The fact it's also broken in Explorer and CMD.EXE is hardly a good testament
to Microsoft's grasp of their own technologies. I've just tested this in
Vista and confirm Explorer and CMD.EXE are still locked to the MAX_PATH
limitation after all these years. We're supposed to be in the age of Vista
and Windows Server 2008 using x64 computing with the ability to address huge
data structures.

Microsoft Word allows users to save documents to extremely long paths. On my
network with 25,000 user accounts, it's not practical to keep renaming their
folders and files to keep them short. It would also interfere with backup
and archiving and they'd lose their shortcuts.

WMI is supposed to be for robust systems programming. The big issue here, is
why the providers have not been updated to use the UNICODE versions of
function calls. It's not difficult to switch the API based on whether the
path begins with \\?\Volume:\Path\File or they could just make the provider
use the updated API as the default (it's backward compatible).
--
Gerry Hickman
London (UK)
Post by Jialiang Ge [MSFT]
Dear Gerry,
I am still researching this post "WMI and MAX_PATH limitation" in the WMI
newsgroup. I searched our support history of Microsoft Customer Support
Service (CSS) department for similar cases, and find that the workarounds
1. Use native Windows APIs instead of WMI.
This point was mentioned in my initial reply, and I understand your concern
that it does not fit your business environment.
2. Write a small application to scan the disk and move away or rename all
the directories with long path (> MAX_PATH).
3. Use "net use" command to access these long file path through a local
redirection.
\\[computer name]\D$\[long dir]\, we may use "net use" command to create a
net use x: \\[computer name]\D$\[long dir]\ and then access the
sub-folder by enumerating the shorter name: x:\.
Based on my experience, this MAX_PATH limit not only appears in WMI, but
http://support.microsoft.com/kb/177665/en-us
http://support.microsoft.com/kb/205345/en-us
The workaround of these problems documented in the KB article are within
the above three points.
Gerry, I totally understand the business impact of this limit on your
product environment and I sincerely want to help you out, however, based on
my research, it is indeed difficult to find out a "perfect" solution at the
moment. Please kindly review my above three suggestions to see whether they
have any chance to help you work around the problem. I also assure you that
the product group will know your concerns and this post will be achieved
for their future references.
Sincerely and best regards,
Microsoft Online Community Support
=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================
Gerry Hickman
2008-10-14 14:23:37 UTC
Permalink
Dear Jialiang Ge,
Post by Jialiang Ge [MSFT]
1. Use native Windows APIs instead of WMI.
This point was mentioned in my initial reply, and I understand your concern
that it does not fit your business environment.
I'd be happy to use this, but it's not compatible with WMI and it's not a
WMI solution. WMI is a client/server technology; when you enum files on a
remote server, the handle to the enumeration is communicated back to the
client. You can target 100 servers and manipulate their FileSystems
independently and in parrallel. You are essentially logged on locally to
each remote server, you are not using SMB calls to the file system from the
client.

I connect from Server A to Server B using WMI. I now want to enum the
FileSystem on Server B. I can do this using the WMI provider using method
calls from the client. I can NOT call the Win32 API on Server B from the
client and maintain communication back to the client from the remote call.
I'd have to upload an EXE image and spawn a new process; at that point the
client/server communication is lost.

If you know a way to call the Win32 API from within a remote WMI session I'd
be happy to use it. I'm happy to use C/C++ for this if it can be made to
work, as long as it doesn't mean writing my own WMI provider.
Post by Jialiang Ge [MSFT]
2. Write a small application to scan the disk and move away or rename all
the directories with long path (> MAX_PATH).
My users would be extremely angry if I keep renaming their files!
Post by Jialiang Ge [MSFT]
3. Use "net use" command to access these long file path through a local
redirection.
Essentially, this is doing the whole thing over SMB which is very different
to manipulating a remote FileSystem locally with WMI. It's hard to explain
why this is a bad idea without writing hundreds of pages on the inner
workings of SMB vs local FileSystem calls.
--
Gerry Hickman
London (UK)
Jialiang Ge [MSFT]
2008-10-16 06:02:17 UTC
Permalink
Hello Gerry,

I discussed this issue with my manager, and am planning for the next
research step. Gerry, I just sent an email to your mailbox, would you
please check it? If you do not get my mail (possibly because my record of
your contact info is not correct), would you mind sending a mail to my
mailbox: ***@microsoft.com?

Thanks
Jialiang Ge (***@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
***@microsoft.com.

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================
Gerry Hickman
2008-10-16 19:27:32 UTC
Permalink
Dear Jialiang Ge,

Thank you for your help researching this issue and working with the
other Microsoft teams and managers.

I'm still interested in a technical answer here of how to call the Win32
API from within a remote WMI session, as this would be useful for many
other WMI applications.

On the wider issue of the MAX_PATH limitation in Windows, I have
considered this again, and I think the main problem is that it's not
consistent across all Microsoft products and technologies. The shell
restricts the path length, but people who have a 'subst' drive to a deep
FileSystem path can break that limit, and anyone who uses Microsoft
office can break that limit, so there will always be file storage to
deep paths. WMI needs to be able to work with those paths.

I write an application to remove old user shares, but this limitation
will make it fail for users who have files with paths greater than MAX_PATH.

This limitation also presents an opportunity for hackers; they can
create their files with very long paths, then place ACLs on those files
which the user can not change, because they are locked out by the
MAX_PATH restriction in the shell, so it's bad for non-technical users.

Thank you for the email with contact information for CSS.
Post by Jialiang Ge [MSFT]
Hello Gerry,
I discussed this issue with my manager, and am planning for the next
research step. Gerry, I just sent an email to your mailbox, would you
please check it? If you do not get my mail (possibly because my record of
your contact info is not correct), would you mind sending a mail to my
Thanks
Microsoft Online Community Support
=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================
--
Gerry Hickman (London UK)
Loading...