GNOME Bugzilla – Bug 680740
Gparted fails when mounting the read-only view of lost filesystems
Last modified: 2012-08-08 16:14:15 UTC
There is a bug in the functionality of Recover lost partitions, in Device-> Attempt to rescue data menu. This bug causes gparted fails to create a read-only view of some rescued filesystems. It seems the error doesn't affect all the recovered filesystems, only some of them. I've been taking a look at the code and, as far as I know, it could be caused because the variables initOffset and totalSize of the Dialog_Rescue_Data::on_view_clicked(int nPart) function are typed as integers (signed), and therefore, on 32 bit machines they cannot hold values greater than 2^31-1, ie: 2147483647. For mount the read-only view, gparted runs the command: mount -o ro,loop,offset=<initOffset>,sizelimit=<totalSize> Based on the tests I've performed, if an incorrect value given to the sizelimit option, the mount can be done without problems. However, it's necessary that the offset value be exactly the correct. For this reason, if any found partition starts on some offset greater than 2147483647 (2gb) it will fail to mount. Just changing the type of this two variables to uint64_t, the problems is solved for me. But I need someone to apply the patch I've attached and make some tests to confirm this is the problem.
Created attachment 219765 [details] The error dialog
Created attachment 219766 [details] [review] Pathc for fix this bug Here's the patch
Good catch Joan. :-) Would you be able to update the patch to use the GParted type "Sector"? This is the internal type that GParted uses for sector values. It is defined in Utils.h as long long. That way if we need to change this in the future, we should only need to change the typedef in this one location.
There is also a typedef named Byte_Value for variables which represent bytes, as opposed to sectors. Currently both of these are defined to be long long.
Created attachment 219814 [details] [review] Bug fixed with Sector type variables Hi Curtis, here's the patch that uses the Sector type.
Hi Joan, Thanks for the updated patch. Do you have a reliable way to reproduce the problem? So far in my attempts gpart has not recognized any partitions I have created. I have tried copying data to the file systems, but so far no luck.
It's hard to make tests with this problem because the result of running gpart is pretty hard to control. But in my experience, it seems is very easy for gpart to find out ntfs partitions, so what I do is create a couple of ntfs partitions in a 6gb hard disk and make the tests with gdb. It usually works.
Thanks for the tip. I used the following steps to test the problem. 1) Create a 6 GB virtual hard disk in a virtual machine 2) Create an msdos partition table 3) Create a 4100 MiB cylinder aligned NTFS partition 4) Create another cylinder aligned NTFS partition to use up the remaining space. I also included the label NTFSTwo during creation. 5) Run gpart and the two NTFS partitions are found. While testing, sometimes one or the other NTFS partitions failed to mount when I clicked the view button. Strangely enough, if I kept trying to View one or the other partition I eventually succeeded in mounting both partitions. This happened with and without the patch. Have you seen similar behaviour?
How strange! I don't know why this happens ... Well, one thing is certain, the fact of using integers for the variables initOffset and totalSize was a mistake in any case, because in this way it couldn't mount partitions located after 2GB . If I'm not wrong, if you try to mount a partition located after the 2GB without having applied the patch, it must necessarily always fail, because the offset will not fit in the integer. Then I'd like you to check, first of all, that indeed the program is able to mount partitions located after the second gb without having applied the patch, because if it works, it is clear that there's some other problem that I overlooked. For my own, I've tested it again and I couldn't recproduce the error. In my case, with the patch applied the view always runs without problems and when I don't apply it, it always fails. You could try to add this two lines before mounting the view: std::cout << initOffset << " " << numSectors << std::endl; std::cout << commandLine << std::endl; If this output is always the same and sometimes works and sometimes not, then this error will probably be caused for any external factor.
Hi Joan, Today I added the error output lines, and tested with and without the patch. Without the patch, partitions larger than 2 GiB failed to mount (as would be expected). Partitions smaller than 2 GiB did succeed to mount. With the patch, I encountered one situation where a 4 GiB partition displayed the error message about failing to mount. I proceeded to try to "View" a partition smaller than 2 GiB, and this partition mounted, and shortly after Nautilus popped up displaying the file system of the 4 GiB partition I earlier tried to mount. This strange mount behaviour seems related to a delay in Nautilus. Most times clicking on "View" mounted the correct partition. The patch certainly does help in mounting partitions > 2 GiB. I plan to commit the patch, with some minor changes to the description. Also, since the initOffset and totalSize appear to be byte values (sector_size * sectors), as opposed to sector values, I will change these to typedef Byte_Value (also long long). I tried to commit the patch earlier, but at the moment I am experiencing problems communicating with the gnome git repository.
The patch in comment #5, along with some changes to description, and minor typedef changes, has been applied to the git repository for inclusion in the next release of GParted. The relevant git commit can be viewed at the following link: Fix failure creating read-only view of rescued file systems (#680740) http://git.gnome.org/browse/gparted/commit/?id=14374c19f3fa49c676bb6a5d2f2eb8b0fdabf4fa Thanks to Joan for identifying and fixing this bug.
Regarding errors with nautilus, I remember when I was developing the first patch to add the feature to find lost partitions, I also used to have problems with nautilus and the use of "gksu-u" for start gparted. Indeed, we were discussing about how to call the system default file browser for not depend on a concrete desktop environment, and finally we decide to use "gnome-open file://{path_to_roview}". It can be probably an external error that we cannot fix because is not in gparted. But in any case, to make sure the patch is working properly, you can run in a sepparated terminal the mount command line that gparted generates.
Now that you mention it, I do recall some problems in this area. I suspect that you are right -- the error is external and something that cannot be directly fixed in GParted.
The patch for this bug report has been included in GParted 0.13.1 released on August 8, 2012.