Bug report #15393
Editing a Shapefile when more than one copy is open can cause corruption
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Severe/Regression | ||
| Assignee: |  Even Rouault | ||
| Category: | Unknown | ||
| Affected QGIS version: | 2.14.5 | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | up/downstream |
| Crashes QGIS or corrupts data: | Yes | Copied to github as #: | 23323 |
Description
Recently (since testing the new LTR version - both 2.14.4 and 2.14.5) we have regularly seen shapefiles become corrupted, with the creation of "_packed" shp and shx components.
We have narrowed down the behaviour to occurring when there is more than 1 copy of that particular layer open (which we sometimes do in particularly complex projects that are used to produce a series of layouts).
It is definitely NOT a case of accidentally having both copies in EDIT mode - there is only ever 1 in edit mode.
I have been able to reproduce this repeatedly with brand new shapefiles, adding a few features, saving, duplicating the layer, then starting edits on ONE layer again (in a project with nothing else open).
All plugins have been disengaged to ensure they are not interfering.
I understand that having more than 1 copy of a layer open may not be 'best practice'... however,
a) this never occurred prior to the use of v2.14 (although we never used 2.12, we did use 2.6, 2.8 and 2.10 versions)
b) if potential corruption cannot be prevented, is it at least possible to get QGIS to pop up a warning or better still, prevent a user from editing a layer if more than one instance of it is open?
Could this be related to the changes to the REPACK function that was worked on to fix the issue with phantom features still appearing in other software even once deleted??
Associated revisions
[OGR provider] Check if REPACK has emitted errors
Refs #15393 and #15570
Real fix for the REPACK issues has been committed per
GDAL ticket https://trac.osgeo.org/gdal/ticket/6672 (GDAL 2.1.2 or above)
Add test to simulate the situations that caused problems.
[OGR provider] Check if REPACK has emitted errors
Refs #15393 and #15570
Real fix for the REPACK issues has been committed per
GDAL ticket https://trac.osgeo.org/gdal/ticket/6672 (GDAL 2.1.2 or above)
Add test to simulate the situations that caused problems.
[OGR provider] Check if REPACK has emitted errors
Refs #15393 and #15570
Real fix for the REPACK issues has been committed per
GDAL ticket https://trac.osgeo.org/gdal/ticket/6672 (GDAL 2.1.2 or above)
Add test to simulate the situations that caused problems.
[OGR provider] Check if REPACK has emitted errors
Refs #15393 and #15570
Real fix for the REPACK issues has been committed per
GDAL ticket https://trac.osgeo.org/gdal/ticket/6672 (GDAL 2.1.2 or above)
Add test to simulate the situations that caused problems.
History
#1
Updated by Nyall Dawson over 7 years ago
- Assignee set to Even Rouault
Even - I've bumped into this a number of times recently too. For me it happens on Windows builds, when having multiple QGIS instances open with the same shapefile in use. Switch the layer to editable in one of the QGIS instances, make some changes, and try to save the changes. I get an error about being unable to reopen the dataset in readonly mode (Which leads me to believe that the changes made to automatically switch ogr sources to readonly are related), and then the shapefile corruption described above. I haven't looked further into it, but my suspicion is that it's caused by the combination of the shapefile packing + the dataset mode switching.
#2
Updated by Jamie Portman over 7 years ago
Has any progress been made on resolving this issue?
It is causing constant grief and loss of data. Individually we make sure we only have one version of a file open, but we are finding others within the organization unknowinly open up files and we are unaware, and therefore result in corrupted files.
We just need to to not let you save if it turns out someone else (or yourself) has a layer open... mapinfo does this - it allows you to do the edits, but when you go to save and it discovers another user has opened the file, it pops up a message saying it cannot save at this time. It at least gives a user the option to go and find the user who has it open or do a save-as and not corrupt data.
#3
Updated by Even Rouault over 7 years ago
- Resolution set to up/downstream
- Status changed from Open to Closed
The fix is in GDAL https://trac.osgeo.org/gdal/ticket/6672. This will land in GDAL 2.1.2
I've committed an improvement in QGIS to raise a QGIS error when GDAL emits a GDAL error + test.
#4
Updated by Jamie Portman over 7 years ago
Thanks Even,
That's greats news.
I had a quick look on the Osgeo/GDAL site but couldn't see any information regarding a release schedule. Do they have a regular 'update' schedule like QGIS or is it more ad-hoc as required? Just trying to get an idea of when GDAL 2.1.2 would be available.
Also, will the installers of QGIS versions automatically pick up the new GDAL version, or can we manually update this for users prior to the next QGIS update (if it is released beforehand).
Apologies if these are dumb questions!
#5
Updated by Jürgen Fischer over 6 years ago
- Category set to Unknown