[parted-devel] Resizing/moving partition with parted-3.0

[Jim Meyering]

Petr Uzel wrote:

> Hi all!
>
> I think that removing FS-related code (and most of the commands like
> mkfs, check,...) from parted-3.0 was a good idea, however I'm a bit
> surprised that resize and move commands are now completely gone. I
> understand why the FS-resizing code has been dropped, but I fail to
> see why it is impossible to do the resizing on partition table level
> (eventually with a warning like "I don't know how big the contained FS
> is and I don't care, so make sure you don't destroy your data").
>
> Is there now any other way how to resize partitions with parted except
> removing/recreating the partition with different size?
>
> Similar with the move command - I might be wrong, but isn't it
> possible just to move the partition including the contents to other
> offset and update partition table? IIRC e.g. NTFS would not survive
> moving to another offset, but in general it should IMHO work. With a
> sufficiently big warning it would be more useful than using dd or some
> similar tool (which moreover wouldn't work if source and destination
> overlap).
>
> Or is there some other reason why resize/move commands have been
> completely removed?

Hi Petr,

I think it is important to cut the cord completely.  Leaving those UI
"commands" or the APIs, but with reduced functionality, would surely
have led some people to presume there had been no change and to end up
losing data.

However, I do see the value in having FS-agnostic move and resize
operators.  At least the grow-in-place subset of "resize" would be handy
for those rare few who use parted directly.  That should be safe for
all file system types.

Do you know of tools that would benefit?  Since it's possible to simulate
them (as you note) by removing and recreating a partition, with or
without an actual data move, I'd see more value in the proposition if
there are existing applications that require this functionality.

Of course, once you talk about actually moving partition data, it's more
efficient to have parted do it, especially when source and destination
overlap -- in which case, the naive manual approach (without parted
support) would involve copying all data to a third location and only
then writing to the destination.  Feasible, but not at all efficient.

So, yes, I think that would be a useful addition.

Are you interested in working on this.

Jim