Community
Participate
Working Groups
Now that the natives for Windows use Unicode calls for handling files (see bug 29584), we should consider using the \\?\ notation to overcome the standard Windows path length limitation on Windows NT/2K/XP. Q: Are there any limitations/extra performance costs when using that notation?
Marking old enhancement requests that we don't intend to fix in the near future as RESOLVED LATER. This does not mean we will never do them, but it means we have no specific plans to address them.
This will be addressed in the next Java major release (mustang). http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4403166
*** Bug 153375 has been marked as a duplicate of this bug. ***
Reopening for consideration. Now that Java 1.5 supports this notation, it is important for our native calls to also use it.
When bugs get duped, the Cc: list members don't get copied over? Bummer.
Fix released. You need to be using a 1.5 JRE to take full advantage of this, because anyone using java.io.File before 1.5 would not be able to interact with files whose paths are greater than 260 characters.
Great Work! Would this be backported to 3.2.x. This stops us from supporting a lot of important cases where resources with long paths are created. Best Regards, Tsvetan
There is a possibility of back-porting this to 3.2.x, but it needs further testing in the 3.3 stream first. Our most important consideration for 3.2.x is to avoid destabilizing the code, so we need to have confidence that there are no side-effects.
*** Bug 172355 has been marked as a duplicate of this bug. ***
*** Bug 186546 has been marked as a duplicate of this bug. ***
Hm, was this now backported on 3.2? We have severe problems with this in our eclipse-based product and are bound to 3.2 cause of plugins and features that are not provided by their vendors in 3.3+ versions. We would take over doing the work (if it is done in reasonable time), but we then would need some pointers which classes to update.
The simplest solution might be to take the 3.3 version of the org.eclipse.core.filesystem plugin and use it in your 3.2-based product. The plugin made only compatible changes between 3.2 and 3.3. Failing that, the changes are in the classes LocalFileNatives and Convert in the org.eclipse.core.filesystem plugin. If you browse the CVS history you can see the changes that were made in November 2006.
It is still possible to reproduce the issue in IES 3.4. Could you please verify this and triage this bugzilla, since we have a customer defect dependant on it and we need to plan in which release the fix will go. Thanks
Jamel, this enhancement is about introducing \\?\ Windows Unicode notation, which we continue to use in Eclipse 3.4. Your best bet is probably to enter a new bug report with a description of the problem you are seeing. I am able to create resources in the workspace with file system paths of arbitrary length on Windows using Eclipse 3.4.
