Feature request #14460
Avoid corrupted qgs files when writing to network drives
| Status: | Open | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | Project Loading/Saving | ||
| Pull Request or Patch supplied: | No | Resolution: | |
| Easy fix?: | No | Copied to github as #: | 22438 |
Description
When user saves a large QGIS project with several layers and complex symbology on a network drive, QGIS becomes unresponsive.
There is no feedback on the screen showing the percentage completed and time remaining. Some users kill the process and will end up with a corrupted qgs file with missing tags. The project will not open any longer and users have to start again.
It will be good if QGIS writes the qgs file to another file (qgs.part for example) and if the process is completed successfully and qgs.part is fully written, file object closed, data safely flushed to disk. And at the final stage, QGIS renames qgs.part to .qgs.
Related issues
History
#1
Updated by Saber Razmjooei over 8 years ago
- Tracker changed from Bug report to Feature request
#2
Updated by Anita Graser over 8 years ago
- Subject changed from Corrupted qgs files to Avoid corrupted qgs files when writing to network drives
#3
Updated by Jürgen Fischer over 8 years ago
QGIS already writes the project file to the temp directory and then copies it to the final destination (see #13299)
#4
Updated by Saber Razmjooei over 8 years ago
Jürgen Fischer wrote:
QGIS already writes the project file to the temp directory and then copies it to the final destination (see #13299)
In that case, it'd be better to have a better feedback to user (e.g. a progress bar) during the save process.
As there is no clear indication of what is happening, user often kills the process and ends up with a curropted qgs file.
#5
Updated by Jürgen Fischer over 8 years ago
Jürgen Fischer wrote:
QGIS already writes the project file to the temp directory and then copies it to the final destination (see #13299)
In case the user kills the process while the project file is still being copied - there should be a temporary file qt_temp.XXXXXX, that has a good copy. But the time consuming process is probably the creation of the temporary file and not the copying (and only for the latter there could be a easy progress indication).
#6
Updated by Giovanni Manghi over 7 years ago
- Easy fix? set to No