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. Dave > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
