Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fixed setting unlimited maximum partition size (#1142)
## Problem - #1065 - The maximum partition size cannot be set to "unlimited", using empty value results in the default maximum size **Example:** Changing the default 2GB max size is not possible, it is always restored back: ![agama_max_size_broken](https://github.com/openSUSE/agama/assets/907998/04bb3f90-dbff-4a7e-99c2-32045162d64d) ## Details - The problem is that the "unlimited" value is represented using the `undefined` value in the web UI. - But `undefined` cannot be sent over D-Bus because D-Bus does not have concept for `undefined`, `nil` or `NULL` values, Iin that case the `MaxSize` is simply missing the sent D-Bus data. - When the D-Bus service creates a `Volume` object it first initializes it with the default data from the YAML product configuration file. Then it updates the attributes using the D-Bus data. Obviously when a value is missing in the D-Bus then it keeps the default value from the config. And that's the problem. ## Solution - Set the "unlimited" value when the `MaxSize` attribute is missing in the D-Bus data. ## Questions - The fix has a drawback, the current code allows sending only partial data set and ensures the defaults from the config file are used for missing values. - This won't work any more for the maximum size as a missing value won't be considered as a "use the default" but as "use the unlimited size". - Can this have some bad consequences? - The code works, but is it safe in all scenarios? ## Alternative Solution - If this fix is not correct then we should probably introduce a new key in the D-Bus data, something like `MaxSizeUnlimited` with `true` / `false` values which can be transferred via D-Bus... ## Testing - Tested manually Now it is possible to unset the maximum size: ![agama_max_size_fixed](https://github.com/openSUSE/agama/assets/907998/067c8108-75d8-40be-9eda-04828bd73e48) --------- Co-authored-by: José Iván López <jlopez@suse.com>
- Loading branch information