Re: [stellation-res] Windows Issues

["Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>]

On Tuesday 20 August 2002 01:47 pm, Dave Shields wrote:
> On Tue, Aug 20, 2002 at 05:09:43AM -0400, Jonathan Gossage wrote:
> > There are a number of places in Stellation where file paths are stored in
> > String objects and these objects are then compared with the equals()
> > method. The problem is that Windows file paths are case insensitive while
> > Unix file paths are case sensitive. This means that these comparisions
> > should be done in a platform sensitive manner.
>
> Indeed they should!
>
> > I need some help from the Stellation team in identifying all the areas
> > where this problem exists in the codebase. So far I know of two areas,
> > the one discussed above and the storage and handling of paths and path
> > fragments used in the "preserves" handling. Another potential area may be
> > the storage of paths in the database itself.
>
> Good point. There are no 'paths' in the database; however, there are the
> names used for the members of CompoundArtifacts, and it would be nice to
> avoid having to deal with case-sensitivity here, lest it overly complicate
> SQL code that accesses the database.
>
> > Once all the areas have been identified, I will develop an initial
> > strategy for dealing with this set of problems and will present it for
> > review by the team before proceeding to implement any changes to deal
> > with this issue.
>
> I suggest mapping all Windows-related path information to lower case early
> on. 

This won't work. While windows considers pathnames to be case insignificant, 
both users and Java compiler's *don't*.  If we map all windows pathnames to
lower case, then checking a Java project out of Stellation will result in
something that con't compile. People also use case in filenames in ways
that are significant to them.


		This lets us keep existing repository access code. I'm in the midst of
> a major cleanup of the workspace code (it's size has dropped from just over
> 13,000 lines to about 10,700 lines). As part of this I have combined the
> current JavaChange (used for Windows) and UnixChange (used for sane
> operating systems) into a single class Change, and moved the
> path-manipulation code to Files. Files now has a method
>   public String getCanonicalPath(String path)
> that returns the 'canonical' form of a path. It's essentially java
> File.getCanonicalPath() on Windows systems, and the standard Unix-style
> normalization on sane systems. We could have it map Windows paths to full
> lower case, and that would solve (I think) most of the problems.

As long as the compounds maintain the case sensitive names, and
use the case sensitive form when outputting to a workspace, this is fine.

	-Mark

-- 
Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work Email: mcc@xxxxxxxxxxxxxx  ------- Personal Email: markcc@xxxxxxxxxxx