Re: unit sizes and parted

[Andreas Dilger]

On Jan 30, 2002  04:30 +1100, Andrew Clausen wrote:
> On Tue, Jan 29, 2002 at 09:33:36AM -0700, Andreas Dilger wrote:
> > > This means parted couldn't figure out the geometry on your
> > > disk... it should have told you.
> > 
> > Well, it didn't mention it, but yes, it was a file and not a disk device.
> > I figured that out after I sent my email, and hence the "need to be able
> > to specify a geometry" in my second email.
> 
> Ah right.  For files, it assumes you don't care about geometry.
> Is there a reason you should care?

Well, for testing or working with images of disks it is useful.  With DOS
partitions, you can generally determine the geometry from the partition
table, and for others you probably don't care.  If there is no partition
table yet or the geometry cannot be determined by the contents, it should
be possible to specify it in some way.

> >  However, even
> > basic recoverability would help.  For example, before I realized that
> > there was no "undo" function I _almost_ wiped the partition table on
> > my primary machine because I wanted to see what GPT partitions looked
> > like (it is perfectly safe to play around with fdisk until you hit "w").
> > Luckily, I decided I should use a test file instead.
> > 
> > Having a backup copy of either the binary or logical structure of an
> > existing partition table would be a huge benefit at very little expense.
> > This might be similar to what LILO does when it first writes the MBR,
> > or the "sfdisk -O <file>" option.
> 
> The only expense is making a nice UI.  All the code in libparted
> is ready (hint: ped_disk_duplicate()).
> 
> But, making a "backup" of a partition table seems like a bad
> idea if the operation also affects on-disk data.

Yes, but in some cases it does not affect the on-disk data, and that
should be possible to recover (e.g. mklabel).

> Also, what about multiple levels of undo?

Nice, but not a requirement.

> Hmmm, here's an idea:
> * you can only undo to the last operation that doesn't modify
> file systrems

Yes, this is the minimum requirement.

> * undo always undoes the last operation... hit undo multiple
> times to go back to the beginning

OK.  Maybe "undo all" as well?

> * redo?  (doable... just have 'where-you-are-at'  be a pointer
> in a list, and when you add an operation, delete the tail of
> the list, and replace it with the operation)

Well, I never understood that much.  If you want to undo something,
just to redo it, you haven't gained very much.  What is much more
useful is to be able to insert or replace an operation earlier in
the stack, then redo subsequent operations.  This is also harder to
implement.  Maybe if you undo, then it keeps the tail operations,
and you then can show, redo, skip/drop, or clear (all) operations
in the tail?

> * warn if you can't undo?

Sure.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/