Comment 1 John Arthorne 2006-03-28 18:02:35 EST

Can you describe why you are using it?  This method is only used on Windows, so unless you are intending to write Windows-specific code you may be using it in error (and causing strange side-effects on non-Windows platforms).

Comment 2 Chuck Bridgham 2006-03-28 22:05:55 EST

Here is our code usage:

if (!WTPPlugin.isPlatformCaseSensitive()) {
			// now look for a matching case variant in the tree
			IResource variant = ((Resource) getProject()).findExistingResourceVariant(getProject().getFullPath());
			if (variant != null) {
				// TODO Fix this string
				return WTPCommonPlugin.createErrorStatus("Resource already exists with a different case."); //$NON-NLS-1$
			}
		}

Comment 3 Arno Unkrig 2007-10-10 04:52:07 EDT

Hi John,

I also need this feature urgently: We need to find resources case-insensitively, e.g. "/prj/fld/XXX.YYY" must find "/prj/fld/xXX.yyY". I can do this either by listing folder "/prj/fld" and then comparing the file names case-insensitively, but that is dreadfully slow. Or I call

    class org.eclipse.core.internal.resources.Resource {
        IResource findExistingResourceVariant(IPath target) { ... }
    }

, but that is an internal API.

I assume that many people need that kind of case-insensitive file lookup.

I propose that you add a method

    interface IResource {
        IResource findExistingResourceVariant();
    }

and an implementation

    class Resource {
        public IResource findExistingResourceVariant() {
            // Same code as the old "findExistingResourceVariant(IPath target)",
            // but uses "this.getFullPath()" instead of parameter "target".
        }
    }

Also, the old internal API should be kept for the next few Eclipse versions for compatibility reasons.

I'd be grateful for a solution, because we have a HUGE performance problem here!


CU

Arno

Comment 4 Szymon Brandys 2008-01-04 09:10:43 EST

(In reply to comment #3)

Do you need this API for the same reason as Chuck needs in the comment #2? If so,
this API would help you both:

public interface IWorkspace extends IAdaptable {
    public IStatus validateCreate(IResources[] resources);
}

This method would check if the resource(s) can be created. So on a case insensitive OS it will return the error status, if a resource with the same name but a different case exists.

Comment 5 John Arthorne 2008-01-04 09:49:27 EST

See also bug 6998.

Comment 6 Szymon Brandys 2008-01-04 11:37:44 EST

To be considered in the future.

Comment 7 Arno Unkrig 2008-03-04 02:32:16 EST

(In reply to comment #4)
> Do you need this API for the same reason as Chuck needs in the comment #2?

No; I don't want to handle case-insensitive file systems, but want to find files case-insensitively. Specifically, I need to determine VERY quickly whether a path with a "similar" name exists. Unfortunately, the current implementation of "findExistingResourceVariant()" performs poorly with large containers.

Comment 8 John Arthorne 2008-03-04 11:37:15 EST

*** Bug 136437 has been marked as a duplicate of this bug. ***

Comment 9 Arno Unkrig 2010-08-26 04:22:48 EDT

Created attachment 177503 [details]
ContainerUtil.java

This class implements a workaround for the missing API.

Again, this issue is NOT about case-insensitive file systems, like NTFS, but about case-insensitive lookup of files, e.g. for case-insensitive programming languages like COBOL.

Comment 10 Arno Unkrig 2011-10-07 08:33:59 EDT

Nobody seems to take care of this one - I give up. Please close.

Comment 11 Szymon Brandys 2011-10-07 08:58:34 EDT

I haven't looked at this report for a while. Let's try to investigate this API requirement for 3.8.

Comment 12 Arno Unkrig 2011-11-15 01:42:56 EST

That sounds great! Maybe a simple method "findResourceCaseInsensitively()"?

Comment 13 Szymon Brandys 2012-03-05 08:01:29 EST

I was thinking where to add this new API. We already have find... methods in IContainer (e.g. findMember) and I think this could be the right place. Since on case-sensitive OS there may be more than one matching resource, we should consider returning an array instead of IResource.
So maybe:

IContainer#findExistingMember(IPath path, boolean caseInsensitive) returns IResource[] or
IContainer#findMembers(IPath path, boolean caseInsensitive) returns IResource[] which would work similar to findMember but would return a list of matching resources on case-sensitive OS.

Comment 14 Szymon Ptaszkiewicz 2012-03-05 08:17:05 EST

I think it would be better to use int memberFlags as additional parameter for the new methods.

Comment 15 Arno Unkrig 2012-03-05 17:06:19 EST

Yes, 'memberFlags' would be nice! That could indicate 'prefix match', 'wildcard match' and/or 'camel case match' in the future!

Comment 16 Dani Megert 2012-03-13 04:45:11 EDT

Is this still on the radar? M6 is API freeze and due this week.

Comment 17 Szymon Brandys 2012-03-13 05:32:42 EDT

I plan to postpone this API change to 4.3. In 3.8 I would like to make all internal code and tests ready. Then in 4.3 we would just expose a new API method.

Comment 18 Szymon Brandys 2012-03-13 05:35:39 EDT

As per comment 17, in M7 I will try to prepare all internal changes so API could be exposed in 4.3.

Comment 19 Szymon Brandys 2012-04-25 11:25:17 EDT

We most likely will not address these bugs during this dev cycle.

Comment 20 Szymon Ptaszkiewicz 2014-04-29 05:37:30 EDT

Too late for API changes in 4.4. Moving to 4.5.

Comment 21 Szymon Brandys 2015-04-01 09:50:19 EDT

I am no longer involved in Platform Core development.

Comment 22 Szymon Ptaszkiewicz 2015-04-01 09:57:48 EDT

Not planned for 4.5.