Ticket #1620 (closed defect: fixed)

Opened 1 year ago

Last modified 9 months ago

bug opening shapefile ind in write mode

Reported by: regodon Assigned to: mloskot
Priority: highest Milestone: 1.4.3
Component: OGR_SF Version: unspecified
Severity: normal Keywords: shape
Cc: warmerdam

Description

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.

Change History

06/21/07 14:05:02 changed by warmerdam

  • keywords set to shape.
  • owner changed from warmerdam to mloskot.
  • cc set to warmerdam.
  • milestone set to 1.4.3.

Mateusz,

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

08/10/07 10:12:59 changed by mloskot

  • priority changed from normal to highest.
  • status changed from new to assigned.

08/16/07 11:33:46 changed by mloskot

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?

08/16/07 18:10:46 changed by warmerdam

Mateusz,

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

08/18/07 07:37:03 changed by mloskot

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.

08/18/07 09:27:12 changed by 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.

10/17/07 10:47:52 changed by mloskot

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?

10/19/07 10:50:03 changed by mloskot

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

10/19/07 10:53:42 changed by mloskot

  • status changed from assigned to closed.
  • resolution set to fixed.

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)
     */

10/23/07 11:29:14 changed by mloskot

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