Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

I have one of my GIS technicians digitizing some lines in QGIS in shapefile format. I don't know how he did it (and neither does he), but somehow the shapefile became corrupt. It was creating random lines or some of the lines he created would just disappear. I went in into ArcCatalogue to see how it looked in ArcGIS and this is what I saw:

enter image description here

Notice the question mark icon where I should see a shapefile 'line' icon. Obviously ArcCatalogue cannot read this file. Also, a second dbf file seemed to have been created with the '_packed' attached to the end. When I look at the shapefile using Windows explorer, I see that there already is a .dbf for the shapefile 'M3_PRE_SMU_lines_10Apr13_SMC.dbf', so I don't know where this _packed shapefile came from and I can't seem to find anything online that speaks to it.

I tried to add this file into ArcMap and I receieved the following error:

enter image description here

The error is pretty self explanatory...number of shapes does not match the number of records. I just don't know why that is occuring. There doesn't seem to be anything online that explains how this is occurring in QGIS, but I do see a couple repair tools. I actually repaired this myself by just opening QGIS, adding the layer, and then right clicking on the layer and 'saving as' another shapefile. So, I've figured a work around, but I'm hoping to find a solution that will stop this from occurring in the first place. Thanks, Mike

share|improve this question
1  
I've been using QGIS for years and have not seen this problem before. The "magical" appearance of another .dbf suggests that the Shapefile has been tampered with outside of QGIS. If you can reproduce the bug using QGIS only, please file a bug report. That would be very important! –  underdark Apr 16 '13 at 16:50
    
I've been trying to replicate the problem with no luck. One thing I did notice is that, unlike in ArcGIS, I do not get a schema lock message when editing in QGIS (i.e. if someone has a schema lock on the shapefile and you start editing the same one, ArcGIS will throw an error when saving edits. QGIS doesn't) I'm thinking that it saves weird when you save a shapefile that's schema locked. I'm not 100% sure this is the cause, but something worth noting. –  Mike Apr 22 '13 at 16:56
    
I've also had this error crop up while editing shapefiles. My work around was just to do my editing in ArcMap. Obviously that's not a real solution - but - you aren't alone in experiencing this kind of error. –  Kevin Oct 3 '13 at 20:36
    
Have you tried to rename the ..._SMC.dbf file to ..._SMC.dbf.backup and the ..._SMC_packed.dbf to ..._SMC.dbf? –  Matthias Kuhn Dec 6 '13 at 10:47
    
hi same problem with Dufur. Files created in the q gis enviroment only. It happens when i'm editing the shape and finally go to save and then stop editing, so the lines disappears and the attributes table seems have not any data. if trying to load again the shape on the qgis it looks empty. In the folder the file es. mario.shx had became a mario_packed.shp. I found that deleting the word packed from the name (it is back mario.shx) the shape is now loaded and seems to be working. How long? don't know i'm just going crazy with this –  user27144 Feb 19 at 22:43
add comment

2 Answers 2

Explanation

OGR is the library used by QGIS to access shapefiles. When OGR deletes features it does not delete them immediately, but just marks the features as deleted. Once in a while, a command called repack is executed, which creates a new file with the suffix _repack and copies all the features which are not marked as deleted to this new file. Once it finishes, the original .dbf is replaced with the _repack.dbf. It then does the same thing to the shapefile: create a new one (_packed.shp), copy all non-deleted features and eventually replace the original .shp.

It seems somewhere in this process, something failed (maybe a crash?).

Within this process, feature ids change, so I guess, that the shp (geometry) you have and the dbf (attribute table) use different feature ids for the same features, what leads to the strange behaviour you experience. It seems, that one of the two files still contains (part of) the deleted features while the other one does not.

How to deal with this

There is probably not a lot you can do about it apart from making regular backups in order not to loose more data than you can handle (you are doing that anyway, right? ;) ). And if you find a way to reproduce this (best with a sample dataset) create a bug.

If you experience this problem again, you can also try to create a spatial index on the shapefile. In this process, QGIS will call repack again on the shapefile, and might "repair" the shp/dbf. But this is just an unverified guess.

There is an issue report with a proposed fix which will be included in QGIS 2.2 and 2.0.2.

share|improve this answer
add comment

Maybe this is another issue of a broken .shx index file. The geometry type should be stored in .shp and .shx header. If they don't match, the software will generate an error.

It looks like QGIS is not very strict on broken index files, and can recreate it with Save As..., while ARCGIS insits on a correct index file, and creates a packed dbf (Attribute table) for the features that could be found via the correct parts of the index file, or maybe without using the index.

share|improve this answer
add comment

protected by Community Feb 20 at 1:28

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.