re - regression window: Problem started sometime between 3.5.10 and 3.6.4.
Similar, but unrelated to this is a limit on the maximum number of characters in the registry key to less than the 'real' maximum for a single API call is 32 * (255 + 1) characters [32 levels deep w/ 255 key length limit + \ separator]. Dynamic length calculation should be used alongside malloc, not _MAX_PATH which is not correct in Windows, especially when Unicode is involved. Problem #1: _MAX_PATH is 260 in Windows, whereas we are hitting a 130 character limit... This is due to the fact that NS_ARRAY_LENGTH is returning the number of elements (characters) in the array. RegQueryValueExW expects that the length passed into it be the number of bytes in the buffer... even though the output is in wide characters. Changing: DWORD pathlen = NS_ARRAY_LENGTH(path); to DWORD pathlen = NS_ARRAY_LENGTH(path) * sizeof(path); Should at least bring the length to 260. Problem #2: Assuming _MAX_PATH in Windows is "really" the maximum path length. This may (hopefully) hold for many function in the C API that Windows exports, especially ones that don't accept an input length on the buffer to be written to (ex: tmpnam). The retrieval of the path from the registry should query the length of the value, then use that to get a properly sized buffer to store the full path in. Querying the length of the path would be done through passing a NULL data buffer in, but passing the address of the data buffer length variable.
This regressed on MC within: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=44c392db6672&tochange=96e8d529b2d3 This includes an Electrolysis Branch Merge to MC. Hence i tried to find a Range on that Branch, but even going back to the first working Windows Build (Built from http://hg.mozilla.org/projects/electrolysis/rev/ef5eac530f66) the Issue is given.
(In reply to comment #2) > DWORD pathlen = NS_ARRAY_LENGTH(path) * sizeof(path); It's redundant because the preprocessor will expand this to "sizeof(path) / sizeof(path) * sizeof(path)". We don't have to consider about "real" maximum path length here because we already depends on MAX_PATH in many places. http://mxr.mozilla.org/mozilla-central/search?string=MAX_PATH Fixing this will be too big to land on the branch for the regression.
I understand about not considering about "real" maximum path length. Also, in depoyment to end user machine, it should usually not be much of a problem. Except when the plugin is deployed for an individual non-admin user instead of the whole machine. In this case, the path can get closer to the limit. For example Google update can have a path like "C:\Documents and Settings\gmzwinge\Local Settings\Application Data\Google\Update\18.104.22.168\npGoogleOneClick8.dll" which is 114 characters. Also, while developing plugin, that path length can be more easily reached due to the multiple hierarchy of folders usually involved in development. Would it be possible to make a change similar to the one proposed by Thomas above? The change goes in mozilla-1.9.\modules\plugin\base\src\nsPluginDirServiceProvider.cpp, in the function nsPluginDirServiceProvider::GetPLIDDirectoriesWithHKEY(). The change could be from: WCHAR path[_MAX_PATH]; DWORD pathlen = NS_ARRAY_LENGTH(path); to: WCHAR path[_MAX_PATH]; DWORD pathlen = sizeof(path); This would double the length of the path. And hopefully should not be too big of a change. Thanks.
Hi Guys, just to update you, finally I found a way to solve it Do you have error messages?, like : * Path too long * Error cannot delete file: cannot read from source file or disk * Cannot delete file: Access is denied * There has been a sharing violation. * Cannot delete file or folder The file name you specified is not valid or too long. Specify a different file name. For that I tried it with: http://longpathtool.com/
Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.