Two corner-case fixes #20
Conversation
By the time get_partnum() is called here, devname may have been modified to it no longer ends with the partition number but instead is a null-terminated device name. That is, dev may still be '/dev/sda3' but devname is now '/dev/sda'. Additionally, the '-n' parameter hasn't been respected, with get_partnum() consistently returning '1' regardless of the actual partition specified on the command line. Only attempt to deduce the partition number if it wasn't already explicitly stated on the command line. This would also be essential if mmc devices should be supported in the future as they're frequently named mmcblk0p1 where a partition name isn't an int but a string. Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
Under certain circumstances we cannot accommodate the size request: the specified size is either greater than or exactly equal to the available length. This is very likely to happen if the user is specifying less precise size values such as MiB, where the number argument is multiplied by a factor or three. Limit this to the actual partition length. It also happens that if you specify the precise number of bytes free, you also, you'll hit an assertion in ped_geometry_test_sector_inside() so we'll bump the request down by one sector and run with that. Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
| opts.size = constraint->max_size * dev->sector_size; | ||
| ped_constraint_destroy(constraint); | ||
| } | ||
| if (opts.size >= dev->sector_size * part_geom.length) { |
There was a problem hiding this comment.
Currently fatresize has two thing that it does, one is obvious, resizing a FAT filesystem, and the other less obvious, resizing the partition on whch a FAT filesystem resides. This would effectively remove the capability to grow the partition, which I actually think would be a good thing.
|
I'm currently hitting some bugs that both these patches solve. The first is that The second is that As noted though, the second commit removes a not well documented "feature" of fatresize, namely the ability to grow the partition that the FAT filesystem resides on. This feature is not without its bugs though. For instance, using Can we at least get the first patch merged? |
|
Do you know a fork where pending patches known to fix and improve stuff are already integrated? |
|
Hi, FWIW at Tails we've been applying a workaround since a few years, that we could ditch once the bug fixed by this MR is fixed. |
4 participants
I found these when I was working with a USB stick with multiple FAT32 partitions and I wanted to resize the last one to fill the remainder of the space on the flash drive. Once merged, these allow calls like the following to work:
The first two would previously fail with the assertion noted in the commit log while the third would complain about overlapping partitions because it would incorrectly deduce that the first partition was the one to be resized since it also happened to match the other conditions (it is also a fat32 partition and
devnamewas modified during use).