Bug report #11761

"handle bad layers" dialog won't consistently resolve within zip containers

Added by Brett Russ over 9 years ago. Updated about 5 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Project Loading/Saving
Affected QGIS version:2.6.0 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:end of life
Crashes QGIS or corrupts data:No Copied to github as #:19993

Description

Background: to reduce file count and overall file sizes, as soon as I realized QGIS could automatically extract shapefiles from within zip files, I used zip files whenever possible for static (read only) layers. I recently moved a subset of my zip files to a new directory and upon launching QGIS I planned to manually resolve all of the filenames. However, this was not as straightforward as I'd hoped.

I originally observed the issues with QGIS 2.2.0 and I just upgraded to 2.6.0 and see slightly different behavior but still problems. With QGIS 2.2, the dialog presented me with 23 layers needing resolution. Most were 3 shapefiles within separate zip files, others were TIF files within zip files. I pointed each SHP and TIF file at the corresponding ZIP and got the warning "there are still 23 unhandled layers that will be lost if you close now". I saw #10212 and upgraded to QGIS 2.6 in hopes of a fix.

In QGIS 2.6, I was presented with the same list of 23 bad layers to fix. Again I pointed all of them to the corresponding zip file. This time, 13 of the original 23 were left unresolved. I could not discover the pattern between those that somehow resolved and the remaining 13 that did not. Half of the zip files with 3 shapefiles resolved while the other half did not, and roughly half of the TIFs within zip files resolved and the rest did not.

Is this type of use of zip containers for layers considered experimental and/or not recommended? Just wondering if I should instead unzip everything and point QGIS layers at each specific SHP, TIF, etc.

History

#1 Updated by Brett Russ over 9 years ago

I hand edited the relative paths according to the form:
/vsizip/<relative-path-to>/<file.zip>/<file-inside-zip.ext>
and have worked around this issue.

However, I wonder what the proper way to "repair" these bad layers in the future is? When presented with a broken path as in the above example, the user can navigate to the zip file which results in a pure absolute path to the zip file, but what code (if any) is responsible for adding the "/vsizip" prefix, changing the absolute path to relative, and adding the necessary "/<file-inside-zip.ext>" suffix?

#2 Updated by Jürgen Fischer almost 9 years ago

  • Category set to Project Loading/Saving

#3 Updated by Giovanni Manghi about 7 years ago

  • Easy fix? set to No
  • Regression? set to No

#4 Updated by Giovanni Manghi about 5 years ago

  • Resolution set to end of life
  • Status changed from Open to Closed

Also available in: Atom PDF