Comment 56 for bug 37768

I am able to reproduce the problem with gparted 0.3.5-1ubuntu3 from hardy; however, I still see the problem when using gparted 0.3.5-1ubuntu4 from hardy-proposed (after a reboot, to ensure that hal and udev were in sane states).

Specifically, the way I am reproducing this is with a USB thumb drive that has two existing partitions that look like so (according to fdisk):

Disk /dev/sdd: 2079 MB, 2079850496 bytes
255 heads, 63 sectors/track, 252 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xc3072e18

   Device Boot Start End Blocks Id System
/dev/sdd1 1 114 915673+ b W95 FAT32
/dev/sdd2 132 186 441787+ 83 Linux

(The oddball layout is due to experiementation with resizing /dev/sdd2.) The first partition is formatted as a fat32 partition, and the second is an ext3 partition. If I then tell gparted to resize the first partition, move the 2nd partition to the end of the device, and create a 3rd partition in between the two, after the resize operation completes, nautilus detects the two existing partitions and mounts them, preventing the fsck of the existing ext3 partition from running.

I've attached lshal output while running gparted; it does look like the lock is getting set based on the line:
  info.named_locks.Global.org.freedeskdesktop.Hal.Device.Storage.locked = true (bool)

Marking verification-failed