Bug 1140512
Summary: | RFE: Print file transfer summary to the log (preferably at info level) | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | David Jaša <djasa> |
Component: | spice-gtk | Assignee: | Pavel Grunt <pgrunt> |
Status: | CLOSED ERRATA | QA Contact: | SPICE QE bug list <spice-qe-bugs> |
Severity: | low | Docs Contact: | |
Priority: | medium | ||
Version: | 7.2 | CC: | dblechte, djasa, fidencio, marcandre.lureau, pgrunt, rbalakri, tjamrisk, tpelka, ylavi |
Target Milestone: | rc | Keywords: | FutureFeature |
Target Release: | 7.2 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | spice-gtk-0.26-5.el7 | Doc Type: | Enhancement |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-11-19 07:34:35 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
David Jaša
2014-09-11 07:31:27 UTC
in new version of the patch info messages are also shown during the file transfer: http://lists.freedesktop.org/archives/spice-devel/2014-September/017446.html (In reply to David Jaša from comment #0) > Description of problem: > It would be cool to know how file transfer was going. A deeper thoughts > would be necessary to make it natural in the GUI but it should be pretty The right solution is to use native OS dnd support. Doing anything else will have other limitations or issues. > easy and non-intrusive to log an INFO message when the transfer is starting > and after it finishes (with some stats such as "transferred file %s of %f > size in %i seconds (%f MB/s)") By info, you mean it should be verbose by default? I disagree as spice-gtk is not a console UI, and it would fit better in debug (quiet by default) > > Version-Release number of selected component (if applicable): > spice-gtk3-0.22-1.el7.x86_64 > > How reproducible: > always > > Steps to Reproduce: > 1. connect with remote-viewer to a guest with file transfer support > 2. transfer a file > 3. look into log for traces > > Actual results: > this is the only message that indicates a file transfer: > GSpice-DEBUG: channel-main.c:980 main-1:0: flushed finished! > (as long as it repeats, the transfer is ongoing) > > Expected results: > messages are printed in INFO level when file transfer starts and finishes, > preferably with some speed/size/time summary. > > Additional info: (In reply to Marc-Andre Lureau from comment #3) > (In reply to David Jaša from comment #0) > > Description of problem: > > It would be cool to know how file transfer was going. A deeper thoughts > > would be necessary to make it natural in the GUI but it should be pretty > > The right solution is to use native OS dnd support. Doing anything else will > have other limitations or issues. > That's way more work, isn't it? I suggested this RFE as a low-hanging fruit so that at least in debugging environments can users see what's going on. > > easy and non-intrusive to log an INFO message when the transfer is starting > > and after it finishes (with some stats such as "transferred file %s of %f > > size in %i seconds (%f MB/s)") > > By info, you mean it should be verbose by default? I disagree as spice-gtk > is not a console UI, and it would fit better in debug (quiet by default) > Yes, I mean verbose by default. The default means logging to ~/.xsession-errors in .el6, to nowhere in .el7 and to auto-rotated journal files in .fc20+ so the only system where this means some permanent use of disk space is RHEL 6 (where ~/.xsession-errors just grows anyway). (In reply to David Jaša from comment #4) > (In reply to Marc-Andre Lureau from comment #3) > > (In reply to David Jaša from comment #0) > > > Description of problem: > > > It would be cool to know how file transfer was going. A deeper thoughts > > > would be necessary to make it natural in the GUI but it should be pretty > > > > The right solution is to use native OS dnd support. Doing anything else will > > have other limitations or issues. > > > > That's way more work, isn't it? I suggested this RFE as a low-hanging fruit > so that at least in debugging environments can users see what's going on. It is certainly more work than adding debug log. If you want to copy file with a progression bar, and cancellation, and subdir etc, I suggest you use shared folders already instead of "xfer". > > > easy and non-intrusive to log an INFO message when the transfer is starting > > > and after it finishes (with some stats such as "transferred file %s of %f > > > size in %i seconds (%f MB/s)") > > > > By info, you mean it should be verbose by default? I disagree as spice-gtk > > is not a console UI, and it would fit better in debug (quiet by default) > > > > Yes, I mean verbose by default. The default means logging to > ~/.xsession-errors in .el6, to nowhere in .el7 and to auto-rotated journal > files in .fc20+ so the only system where this means some permanent use of > disk space is RHEL 6 (where ~/.xsession-errors just grows anyway). Really? Why would you need such log there? Would you expect scp or nautilus to log there too? Let's keep it at debug level. (In reply to Marc-Andre Lureau from comment #5) > (In reply to David Jaša from comment #4) > > (In reply to Marc-Andre Lureau from comment #3) > > > (In reply to David Jaša from comment #0) > > > > Description of problem: > > > > It would be cool to know how file transfer was going. A deeper thoughts > > > > would be necessary to make it natural in the GUI but it should be pretty > > > > > > The right solution is to use native OS dnd support. Doing anything else will > > > have other limitations or issues. > > > > > > > That's way more work, isn't it? I suggested this RFE as a low-hanging fruit > > so that at least in debugging environments can users see what's going on. > > It is certainly more work than adding debug log. > > If you want to copy file with a progression bar, and cancellation, and > subdir etc, I suggest you use shared folders already instead of "xfer". > Ah, that's misunderstanding. I only requested log here. > > > > easy and non-intrusive to log an INFO message when the transfer is starting > > > > and after it finishes (with some stats such as "transferred file %s of %f > > > > size in %i seconds (%f MB/s)") > > > > > > By info, you mean it should be verbose by default? I disagree as spice-gtk > > > is not a console UI, and it would fit better in debug (quiet by default) > > > > > > > Yes, I mean verbose by default. The default means logging to > > ~/.xsession-errors in .el6, to nowhere in .el7 and to auto-rotated journal > > files in .fc20+ so the only system where this means some permanent use of > > disk space is RHEL 6 (where ~/.xsession-errors just grows anyway). > > Really? Why would you need such log there? Would you expect scp or nautilus > to log there too? Let's keep it at debug level. Well, both Nautilus and scp have progress bars (Nautilus with cancel button) so they don't need such a logging. (In reply to David Jaša from comment #6) > > > Yes, I mean verbose by default. The default means logging to > > > ~/.xsession-errors in .el6, to nowhere in .el7 and to auto-rotated journal > > > files in .fc20+ so the only system where this means some permanent use of > > > disk space is RHEL 6 (where ~/.xsession-errors just grows anyway). > > > > Really? Why would you need such log there? Would you expect scp or nautilus > > to log there too? Let's keep it at debug level. > > Well, both Nautilus and scp have progress bars (Nautilus with cancel button) > so they don't need such a logging. scp is a console app, nautilus is a UI. spice-gtk is a UI, you don't interact with the console so you won't see the log in general. If you start the client from the console, you can as well just enable debugging. So what you want is not verbose log, it's a UI. Unfortunately, xfer design doesn't allow to have a good UI presented (it would be an awkward popup). As you said, UI could be done later, but the best approach is to use the guest support & UI for that. Console verbosity is wrong for UI, this progress text should be a debug log. Fixed upstream by the commit: http://cgit.freedesktop.org/spice/spice-gtk/commit/?id=683db0ac922fc13ece04d6a6cd218416c8a7fdf2 new spice-gtk build is under way, and we have a solution for this bug, so propose to include it into the build. Setting back rhel 7.2 flag Sending multiple files simultaneously logs "xfer failed: transfer received success in pending state". Even though hash of the received files matches the ones, which were sent. (and thus the transfer was successful) Do you wish to fix the issue in 7.2 or file it as a separate bug and switch this to VERIFIED? It is reproducible with the previous version of spice-gtk. I would go for a new bug. Filed a new bug( #1265562) . Will switch this one to verified. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-2211.html |