[gdal-dev] Possible bug with creating transactions using the FileGDB driver

[Even Rouault]

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 at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171003/3b16874b/attachment.html>