GDALFindAssociatedAuxFile try to open 'aux' file when baseName is empty

[daim.project@…]

When calling GDALFindAssociatedAuxFile (gdal_misc.p) with pszBasename as an empty string this result in VSIFOpenL (ligne 2411) call with 'aux' as file name : on Windows this is a reserved name to specific I/O , thus the next call to VSIFReadL just hang.

This occur for exemple when creating an 'in memory' VRT datatset using GDALCreateCopy( )  with an empty vrt file name.

In my opinion, GDALFindAssociatedAuxFile should not be called or should return NULL if pszBasename is not specified (NULL or empty string)

[warmerdam]

I have committed a fix for this in trunk, but I am slightly hesitant to back
port to 1.4.x without a test case.  Can you suggest an easy way of reproducing
this problem that I can incorporate into the python test suite? 

[daim.project@…]

Here is a piece of code that should reproduce the problem 

GDALDatasetH hSrcDS = GDALOpenShared(pszAValidRasterfileName, GA_ReadOnly );
if(hDataset)
{ 
  GDALDriverH  hDrv  = GDALGetDriverByName("VRT");
  GDALDatasetH vrtDS = GDALCreateCopy(hDrv,"",hSrcDS,FALSE,NULL,NULL,NULL);
}

If not fixed, this just hang on GDALCreateCopy().

[warmerdam]

It turns out that the logic to try and open an aux file for for utm.tif by
appending .aux "(ie. utm.tif.aux) was broken and was trying "utm.tifaux".  With
an empty path this tried "aux".  I have made the following changes:

 1) Fix the "pure append aux" logic to actually append ".aux" instead of "aux". 
    This fixes the bug of this report. 

 2) Changed the code so the upper case variations are not attempted on windows.
    This is just extra work for nothing. 

 3) Changed the code to return without trying anything if the input path is "". 

I have applied this change in trunk, and am porting it back to 1.3 branch. 

[warmerdam]

I mean porting it back to 1.4 branch of course.