Summary: | ignored case (1GLBMJS) | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Jeff McAffer <jeffmcaffer> |
Component: | Resources | Assignee: | John Arthorne <john.arthorne> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | akiezun |
Version: | 2.0 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | Windows 2000 | ||
Whiteboard: | |||
Bug Depends on: | 5039 | ||
Bug Blocks: | 1943 |
Description
Jeff McAffer
2001-10-10 22:50:09 EDT
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. |