2b4b45ead8
There were (at least) five ways for the volume's nominal size and the volume image file's actual size to desynchronize: - loading a stale qubes.xml if a crash happened right after resizing the image but before saving the updated qubes.xml (-> previously fixed) - restarting a snap_on_start volume after resizing the volume or its source volume (-> previously fixed) - reverting to a differently sized revision - importing a volume - user tinkering with image files Rather than trying to fix these one by one and hoping that there aren't any others, override the volume size getter itself to always update from the image file size. (If the getter is called though the storage API, it takes the volume lock to avoid clobbering the nominal size when resize() is running concurrently.) |
||
|---|---|---|
| ci | ||
| contrib | ||
| doc | ||
| etc | ||
| linux | ||
| qubes | ||
| qubes-rpc | ||
| qubes-rpc-policy | ||
| qvm-tools | ||
| relaxng | ||
| rpm_spec | ||
| templates | ||
| test-packages | ||
| tests | ||
| .coveragerc | ||
| .gitignore | ||
| .pylintrc | ||
| .travis.yml | ||
| installer.wxs | ||
| LICENSE | ||
| Makefile | ||
| Makefile.builder | ||
| README.md | ||
| run-tests | ||
| setup.cfg | ||
| setup.py | ||
| version | ||
Qubes core, version 3
This is master branch of the Qubes OS core.
API documentation is available: https://dev.qubes-os.org/projects/core-admin/en/latest/.