Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 343259

Summary:	[server] Cannot save WebClone 'a' to FS when WebClone 'A' is already created
Product:	[ECD] Orion	Reporter:	Tomasz Zarna <tomasz.zarna>
Component:	Client	Assignee:	Tomasz Zarna <tomasz.zarna>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	john.arthorne
Version:	0.2
Target Milestone:	0.2
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Tomasz Zarna

2011-04-19 08:06:27 EDT

Once the Base64Counter used for WebClones reaches 'Z' the next id it returns is 'a'. The problem is that CloneJob tries to create a location in FS ending with 'a', but there is folder named 'A' already created.

It's obviously a Windows issue.

Comment 1 Tomasz Zarna

2011-04-19 08:49:56 EDT

Fixed[1] (not sure for how long) by starting the counter with 'a'.

[1] http://git.eclipse.org/c/e4/org.eclipse.orion.server.git/commit/?id=d03ba1f13c884af14a8768b406f286884c98bd60

Comment 2 John Arthorne

2011-04-19 09:48:57 EDT

That's not really a fix. That allows maybe 26 more clones before you hit the problem. I suggest adjusting WebClone#nextCloneId...

if (!caseSensitive)
  candidate = candidate.toLowerCase();

Note that Mac OS X is also not case sensitive. Here is the test for case sensitivity we use in core.resources:

public static final boolean caseSensitive = Platform.OS_MACOSX.equals(Platform.getOS()) ? false : new java.io.File("a").compareTo(new java.io.File("A")) != 0;

Since we want to avoid Platform class, Platform.getOS() is equivalent to getting the system property "osgi.os"

WebProject has the same potential problem.

Comment 3 Tomasz Zarna

2011-04-22 07:32:57 EDT

(In reply to comment #2)
> That's not really a fix. 

I agree, I shouldn't mark it as fixed, but it bought me some time.

> WebProject has the same potential problem.

I won't be able to fix for M7, I will look at both in M8.

Comment 4 Tomasz Zarna

2011-05-10 06:28:24 EDT

My initial idea was to modify the Base64Counter.increment() method so on case insensitive OSes it would skip lower case bytes (e.g. increment by 27 when 25 is reached), but since the counter is later on encoded it doesn't make much sense. Then I thought that maybe removing lower case chars from Base64 could be a solution, but that wouldn't violation of the RFC, no go. My final shot was to increment the counter as long as it doesn't produce a lower case char after encoding, but what if the counter has been initialized with a lower case char? Should I then ignore all strings with upper case chars. These ideas all sound clumsy :| John, any tips?

Comment 5 Tomasz Zarna

2011-05-10 06:30:01 EDT

One thing I've got working is a test case, which right now fails at 26:

@Test
	public void testBase64Counter() {
		Base64Counter counter = new Base64Counter();
		List<String> strings = new ArrayList<String>();
		for (int i = 0; i < 10000; i++) {
			String candidate = counter.toString();
			for (String string : strings) {
				assertTrue(new java.io.File(string).compareTo(new java.io.File(candidate)) != 0);
			}
			strings.add(candidate);
			counter.increment();
		}
	}

Comment 6 John Arthorne

2011-05-10 08:57:55 EDT

How about my suggestion in comment #2? We already have a method where we loop until a good candidate is found. In that method we could just force lowercase, which would cause it to skip any names that are duplicated.

Comment 7 Tomasz Zarna

2011-05-11 06:54:13 EDT

(In reply to comment #6)
> How about my suggestion in comment #2? 

Right, forgot about that and got to low. Fixed with http://git.eclipse.org/c/e4/org.eclipse.orion.server.git/commit/?id=baa662fc1e65a919074804a4e14e8ac31be03219. Thanks for your comment.