msSHPOpenFile doesn't detect drive-letter mappings

[ed@…]

I came across this when using indexed (.qix) TILEINDEX files to point to raster 
source images.  There are two problems here, and the second masks the first.

The first problem (and the serious one) is that msSHPOpenFile (at line 1083 in 
the current CVS code) attempts to determine whether the shapefile filename 
already includes a full path or not.  It does so by checking to see if the 
filename string begins with '/' or '\'.  However, a Windows drive-letter mapped 
path ("g:\path\filename") slips through this test.  As a result, the data 
directory path is prepended to this string and the filename ends up looking 
like "g:\path/g:\path\filename" - this value goes in the shpfile->source field.

It appears that this bug is generally benign, because most shapefiles are 
opened just fine (obviously) on Windows with drive-letter mappings.  However, 
when looking for a TILEINDEX file in a raster layer, after the existence of the 
index file is detected, a call to msSHPWhichShapes (mapraster.c, line 1666) 
uses the shpfile->source string to attempt to open the file.  The open fails, 
and the index is ignored.  An error message is generated, but never displayed.

Of course, the image is still generated without the benefit of the index, so 
when msDrawMap finishes, the img is NOT null, which means writeError is never 
called and the error message is not displayed.  I'm not sure whether this is 
correct behavior when the image gets created after all, but it caused me to 
completely miss the error and spend the last few weeks wondering why my testing 
on various permutations of TILEINDEX indexing (with shptree) wasn't making any 
difference at all - all the indices were being ignored.

Changing line 1083 in mapshape.c to:

  if((*filename == '\\') || (*filename == '/') || (*(filename + 1) == ':')) 
{ /* already full path */

will fix this by adding the test for the second character being a colon.