Community
Participate
Working Groups
I noticed that builds are being triggered for all the projects in my workspace (when really nothing should have changed), and then I noticed these curious lines when I turned on tracing: Starting build of gkext @ Tue Jan 25 11:48:20 EST 2005 About to read state... Successfully read state for gkext Classpath jar file E:/pf/ibm/wsad/eclipse/jre/lib/core.jar != Classpath jar file E:/pf/IBM/wsad/eclipse/jre/lib/core.jar Clearing last state : State for gkext (#0 @ Mon Jan 24 17:15:27 EST 2005) FULL build Is this a bug? Shouldn't we be doing case insensitive compares on Windows?
Interesting. The theory is that paths are canonicalized before comparison. We seem to be missing some protection here.
Kent - ask Jerome to show you our canonicalization support.
Gary: which build are you using? Do you have any AccessRestrictions specified on your project(s)? If not then this is likely a dup of bug 73969
Actually what happens when you start your workspace, save, exit and restart? Do you get an identical trace?
(In reply to comment #3) > Gary: which build are you using? > Do you have any AccessRestrictions specified on your project(s)? > If not then this is likely a dup of bug 73969 1) 3.0.1 GM 2) No 3) I skimmed that bug I didn't notice that it talked about case sensensitive matches.
(In reply to comment #4) > Actually what happens when you start your workspace, save, exit and restart? > Do you get an identical trace? I don't remember the exact steps that I took, but since this showed up the log I thought that I would report it, so that it wouldn't get lost. I was zipping an unzipping my workspace, so it is possible that zip changed the case of that directory. But just to be on the safe side, shouldn't these comparisons always be case insensitive on Windows?
If its a one time hit because of a directory rename (or zip file artifact) then I am not inclined to change it. We take the path as is & compare it to what we stored last time. This will only be a recurring problem if the user is constantly renaming the directory.
(In reply to comment #7) > If its a one time hit because of a directory rename (or zip file artifact) > then I am not inclined to change it. > We take the path as is & compare it to what we stored last time. This will > only be a recurring problem if the user is constantly renaming the directory. For my work I do this all the time. I'm running performance benchmarks, so what I do is build up a workspace (to test a particular scenario), and then zip it up. And then I run the benchmark n times, unzipping it before each test. That way the test is always starting from a known state. I realize that most people wouldn't be using the product this way, but it is the way that I use it :-)
Ok - can you verify that the case change is due to zip/unzip?
(In reply to comment #9) > Ok - can you verify that the case change is due to zip/unzip? I recently upgraded zip on all my systems. I couldn't reproduce the problem with my current version of zip. I still don't trust Windows. I know I've seen this problem in the past, but I can't remember any specifics. You can close this if you want, I at least wanted to bring this to someones attention.
thanks we'll keep it around in case it pops up again.
Closing. No more issues there in a long time.
reopening to close properly
no action planned
