On Thu, 2012-12-13 at 10:41 -0500, Chris Lumens wrote: > > (875944) shrinking Windows partition creates an unusable dual-boot setup > > - https://bugzilla.redhat.com/show_bug.cgi?id=875944 > > We're not going to be creating new shrinking UI at this point in the > release cycle. So I just looked at this again. It may be just me, but it may not, so in case anyone else missed it like me: the problem here is that newUI's non-custom shrink path gives the user no opportunity to decide the size of the shrunk partition. It just automatically decides to shrink it to the smallest size anaconda thinks is viable. In oldUI, when you picked 'Shrink an existing partition' from the 'partition options' page, you got a dialog that let you pick the partition to shrink, and the size to shrink it to. In newUI, all you can do is pick a partition and click 'Shrink', and anaconda then decides for you that it should be shrunk to the smallest possible size. You can't change this. dlehman tells me that we take the absolute minimum possible size for the partition (as the tools report it to us) and then pad it by 'the lesser of 10% or 500MB'. This is clearly ridiculous for probably the most common use case - shrink an existing Windows installation and install alongside it. If a regular old person with Windows installed on their entire disk grabs F18 and tries to install Fedora alongside it, following the path we 'expect' - non-custom - they will probably wind up with their Windows partition being 500MB larger than its current contents (I guess fragmentation plays with this, but more or less). That seems to be me to be patently not what they'd actually want. Hell, regular old Mysterious Windows Bloat will probably fill up that 500MB in a week or two, never mind any actual _use_ of the OS. So, yeah, I'm pulling a tentative AWOOGA here: I don't think this shrink functionality is fit for purpose as-is. Many apologies for not catching this earlier, I somehow just never quite grokked that it'd be a big issue. I know adding UI at this late stage is dicey, but I think partition shrinking is fundamentally not something that can be reduced to 'do it or don't do it'. It's not a binary operation. I can't see any way of fiddling with the padding numbers that will give a sensible result in all - or even most - partition resize use cases. I'm not sure we can fix this without adding back the option to set the shrink size, and I think we _do_ need to fix it. If anything, the alternative would be to drop the shrink function from the non-custom path - at least then people couldn't shoot themselves with it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
