Cannot Enable Long Path Names on a Win 32 machine running Win 10 1909
I have tried all three methods described on this page, to enable long path names on a 32 bit machine running Windows 10 1909 Build 18363
The only minor difference is with the gpedit option which refers to the NTFS "Enable LongPathNames" whereas, on a win 32 machine it says "Enable Win 32 LongPathNames"
3 reboots later, all have failed.
Anyone got a better suggestion?
The only minor difference is with the gpedit option which refers to the NTFS "Enable LongPathNames" whereas, on a win 32 machine it says "Enable Win 32 LongPathNames"
3 reboots later, all have failed.
Anyone got a better suggestion?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Joe, yes, your page discusses exactly the same options (which all fail)
Dr Klahn, the test I'm performind doesn't even require an app. I just try to change the name to anything longer than 255 characters (which is 5 less than the alleged limit)
Can't do it. And just tested it on my main 64 bit workstation running 1903 and can't do it on that either!
Dr Klahn, the test I'm performind doesn't even require an app. I just try to change the name to anything longer than 255 characters (which is 5 less than the alleged limit)
Can't do it. And just tested it on my main 64 bit workstation running 1903 and can't do it on that either!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thankyou gentlemen
I now know a lot more about long path names than I ever thought I'd need.
I think the kibosh is <longPathAware>true</longPathAware>
What I was doing my test with (Xplorer Squared) is a red herring. That was just a quick test to see if the registry/policy tweaks had had any effect. The real problem is that the issue arises in the software the client uses to communicate with HMRC. They eventually get to a page which summarises the HMRC calculations and they then need to save a copy to their client folder which is nested to half a dozen levels on a Windoze server. Those levels reflect hierarchy something like Software/Clients/Cliient Folder/Year/Task/Version or similar and that's what creates the long path name. They rarely need actual file names more than 50 characters but often find they're truncated at about 37-40.
I'm almost certain that software won't have that "manifest" option and am somewhat doubtful the authors would even know how to implement it.
I'll do some digging and update accordingly.
I now know a lot more about long path names than I ever thought I'd need.
I think the kibosh is <longPathAware>true</longPathAware>
What I was doing my test with (Xplorer Squared) is a red herring. That was just a quick test to see if the registry/policy tweaks had had any effect. The real problem is that the issue arises in the software the client uses to communicate with HMRC. They eventually get to a page which summarises the HMRC calculations and they then need to save a copy to their client folder which is nested to half a dozen levels on a Windoze server. Those levels reflect hierarchy something like Software/Clients/Cliient Folder/Year/Task/Version or similar and that's what creates the long path name. They rarely need actual file names more than 50 characters but often find they're truncated at about 37-40.
I'm almost certain that software won't have that "manifest" option and am somewhat doubtful the authors would even know how to implement it.
I'll do some digging and update accordingly.
ASKER
question for David Johnson:
that quote:
Initially I needed to know: what is a "manifested Win 32 application" and how do we identify them in the wild? But I got the answer to that here
Did a search for files with a .manifest extension on my system drive and found 27k. Some of which were with applications I recognised, like Syncback (which contained the <longPathAware>true</longPathAware>
and Xplorer Squared (64 bit) which didn't.
So that raised two questions of its own.
First, that wording explicitly excludes 64 bit applications. Does that imply that 64 bit apps do NOT suffer the long path name restriction?
(which is why X2 doesn't include the flag)
Second, can we just edit the manifest to include that string, or will it only work if the code for the actual app is written to support it?
For example, both Outlook and Edge have .manfest files. Neither include longpath awareness. Can I just hack that into the file?
that quote:
will allow manifested Win32 applications and Windows Store applications to access paths beyond the normal 260 char limit per node.raises a couple of questions itself.
Initially I needed to know: what is a "manifested Win 32 application" and how do we identify them in the wild? But I got the answer to that here
Did a search for files with a .manifest extension on my system drive and found 27k. Some of which were with applications I recognised, like Syncback (which contained the <longPathAware>true</longPathAware>
and Xplorer Squared (64 bit) which didn't.
So that raised two questions of its own.
First, that wording explicitly excludes 64 bit applications. Does that imply that 64 bit apps do NOT suffer the long path name restriction?
(which is why X2 doesn't include the flag)
Second, can we just edit the manifest to include that string, or will it only work if the code for the actual app is written to support it?
For example, both Outlook and Edge have .manfest files. Neither include longpath awareness. Can I just hack that into the file?
No comment has been added to this question in more than 21 days, so it is now classified as abandoned.
I have recommended this question be closed as follows:
Split:
-- 'David Johnson, CD' (https:#a43102196)
-- 'Bill Prew' (https:#a43102195)
-- 'Dr. Klahn' (https:#a43102164)
-- 'Joe Winograd' (https:#a43102199)
-- 'Hello There' (https:#a43102359)
If you feel this question should be closed differently, post an objection and the moderators will review all objections and close it as they feel fit. If no one objects, this question will be closed automatically the way described above.
seth2740
Experts-Exchange Cleanup Volunteer
I have recommended this question be closed as follows:
Split:
-- 'David Johnson, CD' (https:#a43102196)
-- 'Bill Prew' (https:#a43102195)
-- 'Dr. Klahn' (https:#a43102164)
-- 'Joe Winograd' (https:#a43102199)
-- 'Hello There' (https:#a43102359)
If you feel this question should be closed differently, post an objection and the moderators will review all objections and close it as they feel fit. If no one objects, this question will be closed automatically the way described above.
seth2740
Experts-Exchange Cleanup Volunteer
I haven't read the article you linked to, so maybe it's the same as my recent EE post on the matter, but here it is:
https://www.experts-exchange.com/questions/29182936/Powershell-Windows-Batch-scanning-folders-with-a-path-too-long.html?anchorAnswerId=43091236#a43091236
There are a few more related posts under that. Regards, Joe