After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 697662 - Do not hide the progress of the tools used
Do not hide the progress of the tools used
Status: RESOLVED FIXED
Product: gparted
Classification: Other
Component: application
unspecified
Other All
: Normal enhancement
: ---
Assigned To: gparted maintainers alias
gparted maintainers alias
Depends on:
Blocks:
 
 
Reported: 2013-04-09 18:59 UTC by 1358
Modified: 2013-09-18 16:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Ntfsresize progress (v1) (1.59 KB, patch)
2013-04-09 22:24 UTC, Mike Fleetwood
none Details | Review
Ntfsresize progress (v2) (1.62 KB, patch)
2013-09-07 19:33 UTC, Curtis Gedak
none Details | Review
Ntfsresize progress (v3) (4.10 KB, patch)
2013-09-08 21:47 UTC, Mike Fleetwood
none Details | Review

Description 1358 2013-04-09 18:59:46 UTC
One of the key features in 0.15 was live tracking of the command progress output in the details log.

gparted, however, asks the tools to not show the progress by passing a --no-progress-bar param (or a short equivalent, e.g. "ntfsresize -P ...").
Because of this, the new progress output is kinda useless, as it does not provide any useful information. In case of ntfsresize for example, only the version is shown.

It would be really helpful, if you could remove these (hard coded?) params.

http://gparted-forum.surf4.info/viewtopic.php?id=16858
Comment 1 Mike Fleetwood 2013-04-09 22:24:28 UTC
Created attachment 241106 [details] [review]
Ntfsresize progress (v1)

Here's a patch which removes the -P flag from ntfsresize.

Also pleasant surprised when the saved operation details only includes
100% complete and not hundreds of line showing every displayed %age.

Hope there aren't any other file system command we are suppressing
useful %ages or progress bars from.

Thanks,
Mike
Comment 2 Curtis Gedak 2013-04-11 01:35:37 UTC
Thank you for the bug report and the patch.

The patch looks good to me, and I plan to test it tomorrow before committing it to the git repository.

Mike,

If you have time, it might be worth checking the copy, resize, and check-repair operations for other file systems to ensure that these are not suppressing text progress information.

Curtis
Comment 3 Mike Fleetwood 2013-04-11 07:58:03 UTC
Hi Curtis,

I've read the manual pages of most of the file system specific commands
we used and found these:

1) ext2/3/4 - Could add "-C 0" to e2fsck to add an ascii text progress
   bar.

2) fat16/32 - Could add "-l" to dosfsck to list file being processed.

3) reiser4 - Could remove "--quiet" from fsck.reiser4 to allow gauges.

4) reiserfs - Could remove "--quiet" from reiserfsck to display rate of
   progress.

5) xfs - Could add "-p seconds" to either xfsdump or xfsrestore to print
   progress every so many seconds.

6) xfs - Could add "-t seconds" to xfs_repair to report progress every 
   so many seconds.

I didn't see anything relevant for: btrfs, hfs, hfsplus, jfs,
linux_swap, lvm2 pv and nilfs2.

I'll have a look at coding these at the weekend.  You can test the
current patch if you want as I won't change that.

Thanks,
Mike
Comment 4 Curtis Gedak 2013-04-11 18:18:53 UTC
Hi Mike,

Wow, it looks like you've found quite a few areas for potential improvement.

Since I am currently trying to get a MythTV PVR repaired/upgraded due to a failed hard drive, I will hold off on testing until later.

Cheers,
Curtis
Comment 5 Phillip Susi 2013-05-02 14:30:08 UTC
This appears to be a dup of Bug 467925 - gparted: add progress bar during operation, which has patches waiting for review.
Comment 6 Curtis Gedak 2013-06-14 17:47:48 UTC
Hi Mike,

I think it is still worthwhile to proceed with this patch, especially with our indecision on bug #467925, and because comment #3 identifies more file system that might be improved.

What do you think?

Curtis
Comment 7 Mike Fleetwood 2013-06-14 18:51:04 UTC
I'll have a closer look at the other file systems to see what's suitable.
Comment 8 Curtis Gedak 2013-09-07 19:33:07 UTC
Created attachment 254355 [details] [review]
Ntfsresize progress (v2)

Hi Mike,

I have taken the liberty of rebasing your patch from comment #1 against the current git master branch.

If possible, I would like to include this fix in the 0.16.2 release because many of our users work with NTFS file systems.

I have reviewed the patch and all looks well to me.  If you are in agreement, we can commit this patch to the git repository.

Regards,
Curtis
Comment 9 Mike Fleetwood 2013-09-08 21:47:05 UTC
Created attachment 254435 [details] [review]
Ntfsresize progress (v3)

Hi Curtis,

I had actually done 90% of what I said I would look at in comment #3.
Just never got around to finishing it off.

Here's version 3.  Changes:

(1) Patch:
    Allow ntfsresize command to report real-time %age progress (#697662)
    Very small comment change.  Drop "Closes".

(2) New patch:
    Enable %age complete display from e2fsck command (#697662)

Thanks,
Mike
Comment 10 Mike Fleetwood 2013-09-08 21:48:11 UTC
And when I tested the file system tool progress indicators, here's why
I decided not to add them to GParted:

1) ext2/3/4 file system resize
   "resize2fs -p ..."
   Draws 3 progress bars from 0 to 40 'X's.  No indication to the user
   how many 'X's will be drawn or a percentage as there is with e2fsck.
   Don't use.

2) fat16/32 file system check
   "fsck.fat ... -l ..."
   Lists every file name being checked.  GParted's operation output and
   log file shows all files.  File names are updated *VERY* fast causing
   GParted to use 100% CPU time.  A large number of files displayed also
   causes GParted to hang for minutes while displaying the operation
   output.
   Don't use.

3) reiserfs file system check
   "reiserfsck ..." without --quiet flag
   Reiserfsck updates VERY quickly causing GParted to use ~70% CPU time
   just displaying the output in the operation dialog.
   Don't use.

4) reiser4 file system check
   "fsck.reiser4 ..." without --quiet flag
   Can't test.  Assume the same as for reiserfs.
   Don't use.

5) xfs file system copy
   "xfsdump -p 10 ..." and/or "xfsrestore -p 10 ..."
   Print a progress statement every 10 seconds.  For even modist file
   systems printing a couple lines of text every 10 seconds quickly adds
   up to a lot of output to display in the operation dialog.
   Don't use.

Never properly tested the xfs_repair case.
Comment 11 1358 2013-09-09 15:10:54 UTC
1) For me, the output of resize2fs looks like:
    Resizing the filesystem on /dev/sdb3 to 863000000 (4k) blocks.
    Begin pass 2 (max = 29815167)
    Relocating blocks             XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Begin pass 3 (max = 36670)
    Scanning inode table          XXXXXXXXXXX-----------------------------

   it seems to be quite obvious that every '-' will be replaced by an 'X' as
   the process proceeds and s.o. can guess if the resize will take about 10
   minutes or about 10 houres.

2) "-l List path names of files being processed." is undoubtedly superfluous

3-4) IMHO detailed output of the file system checks is not that important as
   they can be run easily before starting GParted


Regards,
Tom
Comment 12 Curtis Gedak 2013-09-09 16:09:56 UTC
Hi Mike and Tom,

1)  Thank you Tom for your feedback and indicating how "resize2fs -p"
    works from a terminal.  Unfortunately the printing of the initial
    dashes is undone with the current asynchronous output handling in
    the GParted GUI.  This is because we use CR's and Backspaces to
    remove output from the log file.  This keeps the log file down to
    a reasonable size.  As such when "-p" is added to the "resize2fs"
    command, the user will only see "X"s growing across the screen,
    and not know how many to expect.

    Since changing this handling for a single command is non-trivial,
    and likely not desired,  I think it best to leave improving
    resize2fs progress for the following report:

    Bug #467925 - gparted: add progress bar during operation

2-5)  Agreed.


My review and testing of the patch set in comment #9 has gone well.
As such I have committed this patch set to the git repository for
inclusion in the next release of GParted.

The relevant git commits can be viewed at the following links:

Allow ntfsresize command to report real-time %age progress (#697662)
https://git.gnome.org/browse/gparted/commit/?id=a8b699d896a329c66d412032d7f33139d9a0538d

Enable %age complete display from e2fsck command (#697662)
https://git.gnome.org/browse/gparted/commit/?id=59a22673da55eb185b8bd1e25cc9a729e24c24bb

Curtis
Comment 13 Curtis Gedak 2013-09-18 16:54:39 UTC
The patches to address this report have been included in GParted 0.16.2 released on September 18, 2013.