Having the bug in Intrepid as well, with a USB disk.
One thing I didn't see mentioned (except may be in https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/37768/comments/44) is that the partitioned as mounted by Gnome is still using the *old* partition table, and that even if I unmount it and mount it again with gnome. (I didn't push my luck trying to power off and on again my USB disk, though...)
I find it all the more peculiar that it is suspected, as I understand it, that this spurious mounting is due to gparted asking the kernel to reload the partition table. So I really wonder why Gnome would keep using the old partition informations in that case (bad cache handling?).
However, this bug proved useful: I could backup some data before the partition was actually lost :-P
NB: I checked with fdisk and cfdisk that the partition table was indeed updated. Only Gnome seemed to use the old partition table. I didn't try the "mount" command in a shell.
Having the bug in Intrepid as well, with a USB disk.
One thing I didn't see mentioned (except may be in https:/ /bugs.launchpad .net/ubuntu/ +source/ gparted/ +bug/37768/ comments/ 44) is that the partitioned as mounted by Gnome is still using the *old* partition table, and that even if I unmount it and mount it again with gnome. (I didn't push my luck trying to power off and on again my USB disk, though...)
I find it all the more peculiar that it is suspected, as I understand it, that this spurious mounting is due to gparted asking the kernel to reload the partition table. So I really wonder why Gnome would keep using the old partition informations in that case (bad cache handling?).
However, this bug proved useful: I could backup some data before the partition was actually lost :-P
NB: I checked with fdisk and cfdisk that the partition table was indeed updated. Only Gnome seemed to use the old partition table. I didn't try the "mount" command in a shell.