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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

mikeucfl
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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug with creating transactions using the FileGDB driver

Even Rouault-2

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

> [hidden email]

> https://lists.osgeo.org/mailman/listinfo/gdal-dev

 

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Possible bug with creating transactions using the FileGDB driver

mikeucfl
The fix worked for me, thanks!



--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev