Previously, if a file with UTF-8 encoded characters in its filename was transferred to a Windows guest virtual machine using drag and drop, the UTF-8 characters were not handled correctly and the transferred file had a different name from the source file. In the current release, this has been fixed.
Rebase of upstream to spice-vdagent-win is needed to proper filename encoding of transferred file in Win guests.
+++ This bug was initially created as a clone of Bug #1440206 +++
Description of problem:
Filename of copied file from client to guest is not properly encoded
Version-Release number of selected component (if applicable):
Guest1 - rhel7.4
Guest2 - win10
Steps to Reproduce:
1. Drag&drop file with non ASCII characters in filename (e.g. 'ěščřžýáíé') from client to guest VM
File called '\xc4\x9b\xc5\xa1\xc4\x8d\xc5\x99\xc5\xbe\xc3\xbd\xc3\xa1\xc3\xad\xc3\xa9' is pasted
Dialog window appears: 'An error caused the following file transfer to fail: ěščřžýáíé'
from spice-debug log:
(remote-viewer:5396): GSpice-DEBUG: spice-widget.c:539 drag_data_received_callback: drag a file
(remote-viewer:5396): GSpice-DEBUG: spice-file-transfer-task.c:675 transfer of file ěščřžýáíé has started
(remote-viewer:5396): GSpice-DEBUG: channel-main.c:3104 Insert a xfer task:1 to task list
(remote-viewer:5396): GSpice-DEBUG: channel-main.c:1845 xfer-task 1 received response 2
(remote-viewer:5396): GSpice-DEBUG: spice-file-transfer-task.c:303 File /home/rduda/Downloads/ěščřžýáíé xfer failed: The spice agent reported an error during the file transfer
(remote-viewer:5396): GSpice-DEBUG: channel-main.c:2885 Transfer failed (0x55cdd9839dd0) Transferring 1 files: 0 succeed, 0 cancelled, 1 failed
(remote-viewer:5396): GSpice-WARNING **: File transfer failed with error: Transferring 1 files: 0 succeed, 0 cancelled, 1 failed
(remote-viewer:5396): Spice-DEBUG: channel-main.c:2904:file_transfer_operation_free: Freeing file-transfer-operation 0x55cdd9839dd0
(remote-viewer:5396): virt-viewer-WARNING **: File transfer task 0x55cdd9850290 failed: The spice agent reported an error during the file transfer
File called 'ěščřžýáíé' is pasted to Guest VM
--- Additional comment from Red Hat Bugzilla Rules Engine on 2017-04-07 16:43:57 CEST ---
Since this bug report was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
--- Additional comment from Victor Toso on 2017-04-12 12:36:22 CEST ---
Fix on mailing list
--- Additional comment from Victor Toso on 2017-04-18 14:38:57 CEST ---
Fixed as 5b9ad92814e3fc488cca8cba41b6af0caa390e1b
--- Additional comment from Red Hat Bugzilla Rules Engine on 2017-05-10 14:18:42 CEST ---
This bug report has Keywords: Regression or TestBlocker.
Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release.
Please resolve ASAP.
--- Additional comment from errata-xmlrpc on 2017-05-10 18:50:47 CEST ---
Bug report changed to ON_QA status by Errata System.
A QE request has been submitted for advisory RHBA-2016:25933-01
Upstream agent does not show the problem. Rebase should fix it indeed.
So, it seems that this bug works as expected with new vdagent from bug 1444514 which is currently in ON_QA.
Can be verified after bug 1444514, moving to ON_QA
Adding Fixed in Version based on comment #9
Verified with vdagent-win-4.1-5.
and Win10, Win7 guests.
From rhel7.5 client transfered file (named 'čřýžýíýřáíščúавпр') successfully.
Bug report for the other symbols, which are not allowed in win OS family (see https://bugzilla.redhat.com/show_bug.cgi?id=1450061#c6) was filled: https://bugzilla.redhat.com/show_bug.cgi?id=1520393
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.