[gdal-dev] Locked files under Windows

[Roger Bivand]

On Tue, 5 Nov 2013, Even Rouault wrote:

> Selon Roger Bivand <Roger.Bivand at nhh.no>:
>
>> Hi,
>>
>> This is probably my muddle, but we have an unresolved problem in rgdal on
>> Windows:
>>
>> https://stat.ethz.ch/pipermail/r-sig-geo/2013-October/019667.html
>> https://stat.ethz.ch/pipermail/r-sig-geo/2013-November/019701.html
>>
>> where temporary files created with pDriver->Create() are open and locked
>> under Windows in rgdal/src/gdal-bindings.cpp line 556.
>
> Roger,
>
> The file handle will be released when you destroy the datasource object 
> returned by GDALDriver::Create() (that you should call for other good 
> reasons, such as to free other memory ressources, and to properly flush 
> all data to file). Then you can call unlink(). The fact that Unix system 
> can unlink() a still opened file is a POSIX specific behaviour (I 
> think), whereas Windows doesn't allow that. Nothing to do with GDAL 
> code. So for portable code, file closing should be done before file 
> unlinking.

Even,

Thanks as always for getting back quickly! Yes, the relevant code is (line 
475 in rgdal/src/gdal-bindings.cpp):

   GDALDataset *pDataset =
     (GDALDataset *) R_ExternalPtrAddr(sxpHandle);

   if (pDataset == NULL) return(R_NilValue);

   installErrorHandler();

   GDALDriver *pDriver = pDataset->GetDriver();

   const char *filename = pDataset->GetDescription();

   GDALDeleteDataset((GDALDriverH) pDriver, filename);

   R_ClearExternalPtr(sxpHandle);

   uninstallErrorHandlerAndTriggerError();

but after this is run, the file remains open. Is GDALDeleteDataset() 
inappropriate? Should we say GDALClose((GDALDatasetH)pDataset); first; you 
suggested this instead of pDataset->~GDALDataset(); last year? The file 
pointers are inside the Dataset objects, so obviously they should be 
closed. We have tried putting things in various orders, without success so 
far, I'm afraid.

Best wishes,

Roger

>
> Even
>
>>
>> Under Linux (and possibly OSX, untested by me), unlink() works even though
>> lsof shows them to be open. Because rgdal loads GDAL into a running R
>> session, the undeleted temporary files can accumulate. This is in contrast
>> to use in GRASS or GDAL utilities, where the "owning" process itself
>> terminates quickly, freeing the lock. In gcore/gdaldriver.cpp, I don't see
>> platform-specific fixes; we've been trying mainly with GTiff, but other
>> drivers seem to show the same behaviour.
>>
>> Grateful for any input,
>>
>> Roger
>>
>> --
>> Roger Bivand
>> Department of Economics, NHH Norwegian School of Economics,
>> Helleveien 30, N-5045 Bergen, Norway.
>> voice: +47 55 95 93 55; fax +47 55 95 95 43
>> e-mail: Roger.Bivand at nhh.no
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>

-- 
Roger Bivand
Department of Economics, NHH Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand at nhh.no