Community
Participate
Working Groups
AK (10/9/2001 10:47:49 AM) there exists dir 'a' and a subdir 'Copy Of s' i call findMember("Copy of s") on a and get null (note the different case in 'Of') ok, it doesn't exist so i can create it - but then i get an exception saying that it does exist already. (actually i call IResource::copy to create the new resource) i think, it should either be 'ignore case everywhere in resource names' or 'never ignore case'. currently it is inconsistent. in the ui land - i have no way to tell that the copy call will fail. i check if the resource exists - and it supposedly doesn't. JohnA (10/9/2001 10:25:40 AM) The problem is that Eclipse is always case-sensitive, and your filesystem isn't. It's really difficult to be consistent here, considering we support case-sensitive and insensitive filesystems. You can check the return status from the copy call to see why it failed... It seems acceptable to allow the user to try it, and then the error message should explain why it failed. AK (10/10/2001 12:53:05 PM) then i think findMember should be filesystem-aware. or core should provide another, filesystem-aware, routine to verify the file name another example is: 1GEUO7L: ITPJUI:ALL - magic 'aux' name not handled by refactoring
PRODUCT VERSION: 203
This is a really tricky area. 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, create, copy and move calls will continue to fail when a case variant is detected, but the following status code will be in the exception: IResourceStatus.CASE_VARIANT_EXISTS This will allow clients to handle the case more consistently and gracefully. We know it's not ideal, because you can't quickly test for this as the user types a name. My reasoning is that this case is rare enough that this solution will be acceptable. The user will just get a message saying a conflicting file has been found, and they'll quickly understand how they can work around it. Adam, please give us some feedback if this approach does not work for you.
