[gdal-dev] Possible bug with creating transactions using the FileGDB driver
even.rouault at spatialys.com
Tue Oct 3 13:21:38 PDT 2017
The 2 calls to Stat() are not done in the proper order indeed. Should be fixed per https://
> 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 at lists.osgeo.org
Spatialys - Geospatial professional services
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gdal-dev