Hi, The 2 calls to Stat() are not done in the proper order indeed. Should be fixed per https:// trac.osgeo.org/gdal/ticket/7070
Even > I recently stepped up some code to use Visual Studio 2015 and calling > GDALDataset::startTransaction(true) seems to fail for the FileGDB driver. I > tracked the issue down to cpl_conv's CPLCopyTree method: > > In Visual Studio 2012 the first call to VSIStatL(pszOldPath, &sStatBuf) sets > sStatBuf so st_mode has the flags for a directory. The second call > VSIStatL(pszNewPath, &sStatBuf) fails internally because the new path > doesn't exist, and sStatBuf is remained untouched from the old path's call > (_wstat64 doesn't reset sStatBuf). This worked in favor for the next line > in CPLCopyTree since sStatBuf.st_mode is checked to see if the new path is > a directory (which it says yes because the old path is what set sStatBuf). > > In Visual Studio 2015 _wstat64 clears out sStatBuf. So when VSIStatL is > called on pszNewPath, sStatBuf.st_mode doesn't show that it's a directory > and fails out saying "Unrecognized filesystem object : c:\temp\testing.gdb" > > I'm thinking VSIStatL should check for a -1 response from _wstat64, > indicating the folder doesn't exist and VSI_ISDIR should only check the old > path's sStatBuf to see if it's a folder and not the new path (since it > doesn't exist at this time). Thoughts? > > > > -- > Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Spatialys - Geospatial professional services http://www.spatialys.com
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
