Community
Participate
Working Groups
- create a folder import1 with a subfolder com that contains a file A.java - create a folder import2 with a subfolder COM that contains a file B.java - create a Java project Test - import import1 into the project. It create package com - now try to import import2 into the project. You get a message saying that folder com alreay exists. NOTES: KH (9/14/2001 5:02:58 PM) Moving to Core for comment
PRODUCT VERSION: 125
This is a really tricky area. It stems from the fact that the Eclipse workspace is always case-sensitive, but the file-system may not be. We have been unable to come up with a good solution for this that does not damage performance (I.e., we don't want to be scanning for case variants for operations that need to be quick, such as IResource#exists and IContainer#findMember). What we've decided to try is this: we've introduced a new status code that indicates a local operation has failed due to the unexpected existence of a case variant on a case-insensitive filesystem. So, in the case of this PR, IFolder#create will fail with the following status code: IResourceStatus.CASE_VARIANT_EXISTS This will allow the UI to handle this case gracefully. In the case of import, presumably this means it will ignore the failure and continue with the import. Moving to the UI team for consideration and implementation. Let us know if this approach works for you...
Core has partial support for handling this that does not require upstream client involvement. Please reconsider.
I'm not sure what you mean by that... I'm not sure what partial support you are referring to. We can't blindly overwrite resources on disk that happen to be case variants of what the client is trying to create. The method spec states it will fail if a resource already exists on disk... the change we made just tries to give the caller more information so they know how to deal with the situation. Back to you...
Created core RFC 0001 describing how core handles this case. This RFC has now been through comments and voting. Link to RFC is: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/rfc/0 001/index.html Moving back to UI for handling the import case described by this PR.
I'm a bit confused about why Import should be handled differently than copy, move, and create when a collision occurs. Currently (20020115 build) when you attempt to copy, move, or create and a name collision occurs, an error message is displayed and the operation is aborted. Why should import silently continue when these other operations don't? And even if we attempt to continue, I don't think we should do it silently (i.e., it should be left up to the user to decide what to do). Why not just leave the behavior as is? This is consistent with the rest of the workbench operations.
First of all, the CaseInvariant exception is not thrown on Linux and the import operation works (i.e., resources with the same name but different cases are supported). On WIN, if the CaseInvariant error occurs, import will still continue - just those files with the conflict will not be imported (and an error message at the end of the operation details this - though not as nicely as it could). Let's say I wanted to try to "silently handle" it on Windows, I would have to do something weird to allow the operation to work (e.g., rename the resource folder I am unable to import to match the name of the resource folder it conflicts with so that the CaseInvariant error doesn't occur). This doesn't seem like the right answer. Or maybe when JA says "silently handle" he means don't show the error message at the end. This isn't very user-friendly either (i.e., if you're doing a large import you may not realize some files didn't get imported due to a CaseVariant conflict). So all I am going to try to do is improve the current error message. Currently if you run into a folder conflict for a particular file, you get the following message: "A resource exists with a different case <target folder name>." A better message would be: "Unable to import <source file>: A resource exists with a different case <target folder name>."
Changed error message to be more informative. Attached zip file with changes. Import zip into org.eclipse.ui.
Created attachment 279 [details] zip file with patch
Reviewed and released patch.
