GNOME Bugzilla – Bug 790842
Report libparted messages into operation details at the point at which they occur
Last modified: 2018-03-19 17:08:18 UTC
Created attachment 364415 [details] GParted details of move operation with multiple libparted messages Libparted exceptions messages are reported into the operation details at the end of each separate operation. For operations which involve multiple steps of partition manipulation there is no way to identify which exceptions occurred with which steps. The motivation for raising this was the example reported in bug 790418 comment 10. It was a combined resize/move operation. This involved 1 calibrate and 3 partition resize steps which call into libparted; and because of the bug in 790418 and debugging produced 5 exceptions from libparted, one of which was fatal. There is no way for users or us as developers and supporters to know which libparted actions encountered which exceptions. Operation details from the above case were: Move /dev/sdb to the right and shrink it from 1.15 GiB to ...(ERROR) * calibrate /dev/sdb3 (SUCCESS) * check file system on /dev/sdb3 for errors and (if possib...(SUCCESS) * e2fsck -f -y -v -C 0 '/dev/sdb3' (SUCCESS) * shrink file system (SUCCESS) * resize2fs -p 'dev'sdb3' 1048576K (SUCCESS) * shrink partition from 1.14 GiB to 1.00 GiB (SUCCESS) * check file system on /dev/sdb3 for errors and (if possib...(SUCCESS) * e2fsck -f -y -v -C 0 '/dev/sdb3' (SUCCESS) * grow partition from 1.00 GiB to 1.12 GiB (SUCCESS) * move file system to the right (SUCCESS) * e2image -ra -p -O 134217728 '/dev/sdb3' (SUCCESS) * shrink partition from 1.12 GiB to 1.00 GiB (ERROR) * libparted messages (INFO) * DEBUG: GParted generated synthetic libparted exception... * Error informing the kernel about modifications to part... * Error informing the kernel about modifications to part... * DEBUG: GParted generated synthetic libparted exception... * DEBUG: GParted generated synthetic libparted exception... Need to fix this and report the libparted exception messages at the point in the operation detail results at which they occurred. Then the above operation details whould become something like: Move /dev/sdb to the right and shrink it from 1.15 GiB to ...(ERROR) * calibrate /dev/sdb3 (SUCCESS) * check file system on /dev/sdb3 for errors and (if possib...(SUCCESS) * e2fsck -f -y -v -C 0 '/dev/sdb3' (SUCCESS) * shrink file system (SUCCESS) * resize2fs -p 'dev'sdb3' 1048576K (SUCCESS) * shrink partition from 1.14 GiB to 1.00 GiB (SUCCESS) * libparted messages (INFO) * DEBUG: GParted generated synthetic libparted excepti... * check file system on /dev/sdb3 for errors and (if possib...(SUCCESS) * e2fsck -f -y -v -C 0 '/dev/sdb3' (SUCCESS) * grow partition from 1.00 GiB to 1.12 GiB (SUCCESS) * libparted messages (INFO) * Error informing the kernel about modifications to pa... * Error informing the kernel about modifications to pa... * DEBUG: GParted generated synthetic libparted excepti... * move file system to the right (SUCCESS) * e2image -ra -p -O 134217728 '/dev/sdb3' (SUCCESS) * shrink partition from 1.12 GiB to 1.00 GiB (ERROR) * libparted messages (ERROR) * DEBUG: GParted generated synthetic libparted excepti... This makes it clear exactly which libparted exception occurred against which steps and whether they allowed GParted to continue or not (based on whether the user selected [Ignore], [Cancel] or other).
Created attachment 364417 [details] [review] DEBUG: Create synthetic libparted exception This is a debugging patch I am temporarily using to generate additional libparted exceptions in GParted.
Created attachment 364442 [details] [review] Finer grained libparted message capture (v1) Hi Curtis, Here's patchset v1 for this. Ended up with a lot of small commits with rather wordy messages. I thinking that we shouldn't translate any more GParted Bug messages, and possibly even go back and remove it from the ones we already have. Thanks, Mike
Created attachment 364443 [details] GParted Details log file from resizing a FAT32 partition from 500 MiB to 200 MiB Hi Mike, Thank you for this patch set to improve libparted message handling. In reviewing patch set v1 from comment #2 I came up with the following minor suggested change: P10/12 - Identify libparted messages as either success or error (#790842) Minor wording issue: "successfully" -> "successful" CHANGE FROM: which failed. Instead identify libparted messages as either informational or errors depending on whether this step was successfully ^^^^^^^^^^^^ or not respectively. TO: which failed. Instead identify libparted messages as either informational or errors depending on whether this step was successful or not respectively. I will make this change prior to committing the patch set. In my testing I confirmed no regressions, and also that the libparted messages are now correctly grouped with the respective operational steps. The attached gparted_details.html log file is from resizing a 500 MiB FAT32 partition down to 200 MiB. When prompted to convert to FAT6 by libparted, I chose "Ok". If there are no objections then I will commit this patch set in the next day or so. Curtis
Patch set v1 from comment #2 has been committed to the git repository. The relevant git commits can be viewed at the following links: Also stop OperationDetail execution timer when setting status to N/A (#790842) https://git.gnome.org/browse/gparted/commit/?id=3c1fdd14f4d902ad5abcacd860a41bc179fadec6 Add mechanism to stop adding more child OperationDetails (#790842) https://git.gnome.org/browse/gparted/commit/?id=f8f9a72de699843a9a780f89d10d6ea615ed732b Add mechanism to capture exception messages into an OperationDetail (#790842) https://git.gnome.org/browse/gparted/commit/?id=2ed7feb2f56e18974dcaea14b68de05409847d79 Capture libparted messages via callback at top-level only (#790842) https://git.gnome.org/browse/gparted/commit/?id=23939331f652d53eb8146f140d69814c487cfb35 Allow child OperationDetails to emit error capture callback too (#790842) https://git.gnome.org/browse/gparted/commit/?id=0a78c3985678549b4781b7b19fbb0a51475e2086 Transition code using libparted to callback error collection (#790842) https://git.gnome.org/browse/gparted/commit/?id=76088a39de363806ad972ed8822905408e6a2225 Refactor ntfs resize code (#790842) https://git.gnome.org/browse/gparted/commit/?id=bf1e87ecf31843d38fae416fdf66de3511b00f92 Transition other code to callback error collection (#790842) https://git.gnome.org/browse/gparted/commit/?id=2040aabd22b8ef7da46a9596bfece0b903b17e7f Set the status last for the OperationDetails in mk/rm_temp_dir() (#790842) https://git.gnome.org/browse/gparted/commit/?id=b4cd5da4f7ff10f4eb7f9ea923491666b3bfea63 Identify libparted messages as either success or error (#790842) https://git.gnome.org/browse/gparted/commit/?id=068866205531d49f4a090aab0c1b4aa6aee9b2be Rename OperationDetailStatus STATUS_N_A to STATUS_WARNING https://git.gnome.org/browse/gparted/commit/?id=8c5c13d613474d3853d6071c5be8055d49bef5aa Remove left behind #include "ProgressBar.h" https://git.gnome.org/browse/gparted/commit/?id=f9ae35584beeaac0230fdef92ae9923e6ea40466
Hi Mike, > I thinking that we shouldn't translate any more GParted Bug messages, > and possibly even go back and remove it from the ones we already have. 'Sorry I overlooked this before. Why do you think we shouldn't translate GParted Bug messages? In general I think it is useful to non-English speaking users to have all messages displayed in their language. The reason being is that it may empower them to identify and fix the issue themselves. If any message is in a completely foreign language to them, then they may have no clue what the problem is. This would be me if the message was in Chinese. I would have no idea if it was something I did wrong, the program did wrong, or a hardware issue. I know that it can make it harder for us to respond when we receive a problem report with foreign language message strings. However, we do have the advantage of being more familiar with the code and hence can usually figure out what the original messages in English would be. Curtis
Hi Curtis, I don't have strong opinion either way about whether bug messages should be translated or not. I guess I was being persuaded by the opinion of one translator [1] over that of another [2] back from when we released GParted 0.28.0. At least earlier GParted bug messages were in relation to concepts users were already dealing with of partitions and operations. This is just to do with misuse of some internal OperationDetail object. It seems harder to phrase is such a way that a translation would be meaningful to a user. Anyway If you want it translated I will translate it. Mike [1] Florian said: So then they should better not be translated. Otherwise you may get bug reports send back to you in 50+ different languages ... https://mail.gnome.org/archives/gnome-i18n/2017-February/msg00018.html [2] Ask said: On the other hand, if I were to get an English message in a program which I knew to be translated, that would also be grounds for reporting an error. https://mail.gnome.org/archives/gnome-i18n/2017-February/msg00019.html
Hi Mike, Thanks for the links to the differing opinions. In my opinion if GParted outputs a message to the user, then that message should be available to be translated. If it is an internal GParted bug that should never occur then I still think we should try to word the message so that translators and users can understand it at a high level. Curtis
Created attachment 364850 [details] [review] Make bug message translatable (v1) Hi Curtis, Here's a patch to make that bug message translatable. Hopefully the message and translator help are understandable to their respective recipients. Thanks, Mike
Thanks Mike for patch v1 to make the GParted bug message translatable. Patch v1 from comment #13 has been committed to the git repository. The relevant git commit can be viewed at the following link: Make OperationDetail no_more_children bug message translatable (#790842) https://git.gnome.org/browse/gparted/commit/?id=c7ee9934f1dff8281907b0d7786c086158b30188
Created attachment 365384 [details] [review] Set OperationDetail status last during internal copy benchmarking (v1) Hi Curtis, I've found another place where I've let the new warning bug occur about adding more information into an operation detail after setting its final status. This patchset fixes that. Thanks, Mike
Thank you Mike for finding this minor issue and fixing it. Patch set v1 from comment #10 has been committed to the git repository. The relevant git commits can be viewed at the following links: Set OperationDetail status last during internal copy benchmarking (#790842) https://git.gnome.org/browse/gparted/commit/?id=e5ccb3b8bc2ad3bf1c06c41bc8a97bcf5c11e27d Match up OperationDetail creation and status setting for internal copy (#790842) https://git.gnome.org/browse/gparted/commit/?id=ff0360eb4f571ce77ea9fc1c8ff774e416a6e34b
This enhancement was included in the GParted 0.31.0 release on March 19, 2018.