On Tue, 2009-03-31 at 19:20 +0200, Radek Vykydal wrote:
David Lehman wrote:
On Mon, 2009-03-30 at 18:18 -1000, David Cantrell wrote:
---
storage/formats/__init__.py | 30 ++++++++++++++++++++++++++++++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/storage/formats/__init__.py b/storage/formats/__init__.py
index 9ec0999..60be55e 100644
--- a/storage/formats/__init__.py
+++ b/storage/formats/__init__.py
@@ -149,6 +149,9 @@ class DeviceFormat(object):
_minSize = 0 # minimum size in MB
_dump = False
_check = False
+ _wantFormat = False
wantFormat is equivalent to 'not self.exists'
Is it true for existing partitions we want to format?
It should be. We probably do not handle correctly the case of re-editing
a preexisting partition and unchecking 'format' after having checked it
in the initial edit. In this case we should use the device tree to look
up the ActionDestroyFormat and ActionCreateFormat and cancel them both.
I see the new want* properties more as a place to store information for UI.
When I was thinking about how to fix UI edit flow (multiple editing) of
existing
partitions, I was trying another approach - to store original (in the
sense of UI)
format in device instance attribute or ui (in deviceinstance-keyed dict)
and create
the dialog based on actual device format and stored original format, but
it started
to become too clumsy and complicated.
I wanted to achieve that for existing partitions, re-edit would mean
starting
from the same point (preexisting format) so that you could e.g. decide
to migreate
(from original fs) instead of format when reediting the partition - this
would also
require canceling of format action planned in previous edit.
Right -- this is something we would need to do in any case if we have
scheduled a format action that we do not want to actually execute. For
new devices we can just schedule more actions and they get sorted out by
DeviceTree.pruneActions, but it has the same effect.