RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1140512 - RFE: Print file transfer summary to the log (preferably at info level)
Summary: RFE: Print file transfer summary to the log (preferably at info level)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: spice-gtk
Version: 7.2
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: rc
: 7.2
Assignee: Pavel Grunt
QA Contact: SPICE QE bug list
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-11 07:31 UTC by David Jaša
Modified: 2015-11-19 07:34 UTC (History)
9 users (show)

Fixed In Version: spice-gtk-0.26-5.el7
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 07:34:35 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2211 0 normal SHIPPED_LIVE virt-viewer, spice-gtk, and libgovirt bug fix and enhancement update 2015-11-19 08:27:40 UTC

Description David Jaša 2014-09-11 07:31:27 UTC 
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 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)")

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:
Comment 1 Pavel Grunt 2014-09-16 08:51:40 UTC 
sent patch
http://lists.freedesktop.org/archives/spice-devel/2014-September/017418.html
Comment 2 Pavel Grunt 2014-09-22 10:25:26 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
Comment 3 Marc-Andre Lureau 2014-10-06 13:30:00 UTC 
(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:
Comment 4 David Jaša 2014-10-07 07:19:04 UTC 
(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).
Comment 5 Marc-Andre Lureau 2014-10-07 07:46:45 UTC 
(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.
Comment 6 David Jaša 2014-10-07 09:10:41 UTC 
(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.
Comment 7 Marc-Andre Lureau 2014-10-07 09:31:38 UTC 
(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.
Comment 8 Pavel Grunt 2015-08-26 07:10:09 UTC 
Fixed upstream by the commit:
http://cgit.freedesktop.org/spice/spice-gtk/commit/?id=683db0ac922fc13ece04d6a6cd218416c8a7fdf2
Comment 9 David Blechter 2015-08-28 19:45:59 UTC 
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
Comment 12 Tomas Jamrisko 2015-09-22 15:02:31 UTC 
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?
Comment 13 Pavel Grunt 2015-09-22 15:14:58 UTC 
It is reproducible with the previous version of spice-gtk. I would go for a new bug.
Comment 14 Tomas Jamrisko 2015-09-23 08:44:27 UTC 
Filed a new bug( #1265562) . Will switch this one to verified.
Comment 17 errata-xmlrpc 2015-11-19 07:34:35 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.