Request For Comment

Eclipse Platform Core RFC 0001

Case Variant Collisions During Resource Creation.

The Eclipse workspace is always case-sensitive, but some filesystems are not. This causes a problem when trying to create a file using the Core API, in the case where a file already exists at the target location that differs only in case from the file being created. This document discusses the problem and evaluates various approaches to solving it.

By John Arthorne, OTI.
Created: November 26, 2001
Last Modified: January 4, 2002

The Problem

Let us define three resource handles:
	IProject project = ResourcesPlugin.getWorkspace().getRoot().getProject("Project");
	IFile abc = project.getFile("abc.txt");
	IFile ABC = project.getFile("ABC.txt");
The initial state of the problem is when project and abc already exist. If a Core API method is used to create ABC (using either create, copy, or move API methods), an exception is thrown. The exception detail states that the file could not be created because it already exists. The contradiction is that ABC.exists()will return false, since the case sensitive workspace does not recognize the collision with abc. Likewise, lookup methods such as project.findMember("ABC.txt") will also fail to locate the existing file abc, leading the API user to believe that it is ok to go ahead and create ABC.

Note that this is not quite the same as when a case variant already exists in the file system, but not in the workspace. Following the above example, say a local file "abc.txt" does not exist in the workspace, but is created externally in the filesystem. In this case, the current behaviour when a client calls ABC.create() is consistent; it throws an exception stating that the workspace is out of sync with the local filesystem.

New comment: It should be noted that this problem arises from the fact that the platform case sensitivity does not always match the case sensitivity of the underlying filesystem. In most cases, this inconsistency can be handled by the platform core without requiring special handling by callers of core API. However, this situation represents one rare corner case that cannot be resolved silently. This is because "under the covers" resolution would require core to delete files from the filesystem without user awareness.

Proposed Solution

The proposal is to add a new core status code, IResourceStatus.CASE_VARIANT_EXISTS. This status code would be included in exceptions from all create, copy, or move API methods in the IResource hierarchy, when a case variant already exists at the target location. The exception will also include an appropriate error message describing why the creation couldn't continue. Feedback: Each project can be associated with a different repository and the versioning abilities of that project are governed by the target repository (adapter). It seems strange that we would not argue that a project's case sensitive behavior wouldn't be based on the target file system it was stored on.

Response: Yes, you could argue that this approach would give a more consistent user experience. However, this would unfortunately require a radical redesign and a major overhaul of large amounts of platform code. What this solution proposes is the best we could come up with under the constraints of the existing architecture.

Alternative Solutions

This section describes proposed alternative solutions, and some comments on them. More alternative solutions will be added as they are raised during discussion. Please feel free to add to or dispute any pros and cons already listed.

Make the Workspace Case-Sensitivity Match the Filesystem

With this approach, when the Eclipse workspace is run on a case-insensitive operating system, the workspace would never be case-sensitive. On case-sensitive operating systems, the workspace would always be case-sensitive.

Related Bugs:

RFC Status

This proposal is has been voted on and accepted.