bug opening shapefile ind in write mode

[regodon]

We have a cgi which calls ogrinfo and we are getting an error opening index.

# /usr/local/FWTools/bin_safe/ogrinfo -ro -al -sql "SELECT NOMBRE FROM municipios-noacentos WHERE PROVMUN='28079' ORDER BY SHAPE_AREA DESC" /var/www/meteosig/data/sms/municipios-noacentos.shp

[pid 28205] open("/var/www/meteosig/data/sms/municipios-noacentos.shp", O_RDONLY) = 3
[pid 28205] open("/var/www/meteosig/data/sms/municipios-noacentos.shx", O_RDONLY) = 4
[pid 28205] open("/var/www/meteosig/data/sms/municipios-noacentos.dbf", O_RDONLY) = 5
[pid 28205] open("/var/www/meteosig/data/sms/municipios-noacentos.prj", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 28205] open("/var/www/meteosig/data/sms/municipios-noacentos.idm", O_RDONLY) = 6
[pid 28205] open("/var/www/meteosig/data/sms/municipios-noacentos.ind", O_RDWR) = -1 EACCES (Permission denied)

ogrinfo tries to open the index file in readwrite mode? Is it a bug or is it necessary? We need fast queries, but we don't want to change owner of shapefiles to "apache".

We are using FWTools 1.2.1

==================================

Reply from Frank:

I see your point! The problem is the poINDFile->Open() call in gdal/ogr/ogrsf_frmts/generic/ogr_miattrind.cpp. Could you file a bug report directly against GDAL/OGR for this issue? I will have Mateusz fix it as soon as is practical.

[warmerdam]

Mateusz,

Aiming for 1.4.3. Let me know if you have questions.

[Mateusz Łoskot]

Frank,

One thing is not clear to me in this ticket. Does Shapefile driver use .ind files or the issue is related to MapInfo driver only but incorrectly titled?

[warmerdam]

Mateusz,

The Shapefile driver does (oddly) use the mapinfo .ind file for indexing attributes. This is an OGR convention, not an ESRI thing.

[Mateusz Łoskot]

Frank,

I understand.

So, according to my understanding the fix seems to be pretty small: replace r+ with r in miattrind.cpp:227

    if( poINDFile->Open( pszMetadataFilename, "r+" ) != 0 )

Unless, the poINDFile needs to be writable somewhere after loaded from file. If there is such a chance, I will track all execution paths.

[warmerdam]

Mateusz,

I'm not sure. You should check what happens if an existing index is re-created. I *think*, the index should be opened with the same read/readwrite status as the rest of the dataset but I'm not sure.

[Mateusz Łoskot]

Frank,

I agree with your last comment about using consistent perms while opening files, but the problem is that the r+ is hardcoded in miattrind.cpp:227 and I can't think about any way how could I query for access mode used to open other files of given datasource (.shp/.dbf). This information seems to live on level that's inaccessible from OGRMILayerAttrIndex and TABINDFile classes.

So, the dirty solution is to replace hardcoded r+ with hardcoded r in function OGRMILayerAttrIndex::LoadConfigFromXML().

What do you think?

[Mateusz Łoskot]

Just for keeping things in files, Frank has given me the liberty to decide what solution to use.

[Mateusz Łoskot]

Fixed in r12482

Important note (ogr_miattrind.cpp:228):

    /* NOTE: Replaced r+ with r according to explanation in Ticket #1620.
     * This change has to be observed if it doesn't cause any
     * problems in future. (mloskot)
     */

[Mateusz Łoskot]

I've ported the fix to branches/1.4 (r12519)

[Even Rouault]

I've fixed in trunk an issue related to that ticket : if an index already existed, as it was opened in 'r' because of r12482, a CreateIndex() would fail but silently

Other minor issue discovered when instrumenting fopen()/fclose()/unlink(), when the last index on a table is dropped, the .ind file was unlink()'ed before closing it. We should differ the unlink() of the file after closing it to be on the safe side. Otherwise, it could prevent the .ind file to be deleted on Windows

Fixed in trunk (r19745) and in branches/1.7 (r19747). Tested in r19746.