[parted-devel] Bug: Removal of BLKPG causes regression of ability to manipulate disks with other partitions in use

[Phillip Susi]

On 3/29/2010 12:11 PM, Petr Uzel wrote:
> Imagine you add partitions with parted in a script. Then the ioctl()s
> are:
> 
> #create 1st partition
> BLKPG_ADD_PART (sda1)  [A]
> 
> #create 2nd partition
> BLKPG_DEL_PART (sda1)  [B]
> BLKPG_ADD_PART (sda1)
> BLKPG_ADD_PART (sda2)
> 
> [A] triggers udev, which runs hal, which asynchronously opens
> /dev/sda1
> [B] sda1 is still opened by hal -> EBUSY
> 
> And there is a good chance that 0.5s after [B], the hal will release
> the device and BLKPG would succeed.

This is not a problem since when you get EBUSY removing A, it is ignored
since A is unmodified.  It does not matter whether A is busy because of
a transient open from hal, or because it has actually been mounted,
since we aren't trying to modify it, we don't care that it is busy.

>> If we got to this point then linux_partition_is_busy() already checked
>> and thought that the partition was not mounted.  If it does, then parted
>> denies the request to remove the partition  before ever trying to sync
>> the partition table.
> 
> I don't think so. If I'm not mistaken, it is checked only if parted is
> explicitly instructed to remove given partition, but not if the
> partition is added/removed in _disk_sync_part_table().

Right, but again, we only care about EBUSY on the partition we are
actually trying to modify.  If we get EBUSY on the other partition, we
don't need to retry since we don't care that it failed.

> If you are sure that failed ioctl does not alter the third argument
> (I'm not BTW), then OK. On the other hand, short comment that error
> checking is not necessary wouldn't hurt :) Sorry if this is
> nitpicking.

Indeed, a comment would not hurt ;)