Opened 17 years ago

Closed 14 years ago

#1620 closed defect (fixed)

bug opening shapefile ind in write mode

Reported by: regodon Owned by: Even Rouault
Priority: highest Milestone: 1.7.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 (14)

comment:1 by warmerdam, 17 years ago

Cc: warmerdam added
Keywords: shape added
Milestone: 1.4.3
Owner: changed from warmerdam to Mateusz Łoskot

Mateusz,

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

comment:2 by Mateusz Łoskot, 17 years ago

Priority: normalhighest
Status: newassigned

comment:3 by Mateusz Łoskot, 17 years ago

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?

comment:4 by warmerdam, 17 years ago

Mateusz,

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

comment:5 by Mateusz Łoskot, 17 years ago

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.

comment:6 by warmerdam, 17 years ago

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.

comment:7 by Mateusz Łoskot, 16 years ago

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?

comment:8 by Mateusz Łoskot, 16 years ago

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

comment:9 by Mateusz Łoskot, 16 years ago

Resolution: fixed
Status: assignedclosed

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

comment:10 by Mateusz Łoskot, 16 years ago

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

comment:11 by Even Rouault, 14 years ago

Milestone: 1.4.31.7.3

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.

comment:12 by Mateusz Łoskot, 14 years ago

Resolution: fixed
Status: closedreopened

comment:13 by Mateusz Łoskot, 14 years ago

Owner: changed from Mateusz Łoskot to Even Rouault
Status: reopenednew

comment:14 by Mateusz Łoskot, 14 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.