[Spice-commits] 2 commits - vdagent/file_xfer.cpp

[Christophe Fergau]

 vdagent/file_xfer.cpp |   16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

New commits:
commit 6c070843cb00635bc8bab5fd98b8fefb597e7557
Author: Cody Chan <int64ago at gmail.com>
Date:   Wed Aug 13 23:43:56 2014 +0800

    Fix g_key_get_string() failure when string contains '['
    
    In vd_agent/file_xfer.cpp is implemented a simple g_key_get_string,
    but  when dragging a file with a name containing '[' (like te[st.txt),
    it will fail.
    From source code,
    >next_group_pos = strstr(group_pos + strlen(group_pfx), "[");
    >    if (next_group_pos && key_pos > next_group_pos) return false;
    we know that it tries to find the end of current group by '[' label,
    if we drag a file named te[st.txt, the key_string will be like:
    [vdagent-file-xfer]
    name=te[st.txt
    size=10
    so, it will fail when meta parsing and returns the
    VD_AGENT_FILE_XFER_STATUS_ERROR message.
    
    Here's the elegant method Christophe proposed and test ok, thanks to
    him again!

diff --git a/vdagent/file_xfer.cpp b/vdagent/file_xfer.cpp
index 9eec5cc..208303f 100644
--- a/vdagent/file_xfer.cpp
+++ b/vdagent/file_xfer.cpp
@@ -206,7 +206,7 @@ bool FileXfer::g_key_get_string(char* data, const char* group, const char* key,
     snprintf(key_pfx, sizeof(key_pfx), "\n%s=", key);
     if (!(key_pos = strstr(group_pos, key_pfx))) return false;
 
-    next_group_pos = strstr(group_pos + strlen(group_pfx), "[");
+    next_group_pos = strstr(group_pos + strlen(group_pfx), "\n[");
     if (next_group_pos && key_pos > next_group_pos) return false;
 
     start = key_pos + strlen(key_pfx);
commit 21b79679c1345225ceba8d015f5efe9113d146fb
Author: Cody Chan <int64ago at gmail.com>
Date:   Wed Aug 13 23:02:19 2014 +0800

    Fix dragging of files with CJK characters in name
    
    I submitted a patch several months ago about this issue,
    here http://lists.freedesktop.org/archives/spice-devel/2014-February/016158.html
    I check it again, and find that the value of
    g_key_file_to_data(keyfile,...) is always utf-8, for the value of
    g_uri_list_extract_uris() is utf8 urlencode.
    
    So the display problem is caused by vd_agent, but how it displays
    depends on the language of system, the following two screenshots show
    the difference:
    
    http://int64ago-tmp.qiniudn.com/guest-Chinese.png
    http://int64ago-tmp.qiniudn.com/guest-English.png

diff --git a/vdagent/file_xfer.cpp b/vdagent/file_xfer.cpp
index e402eb2..9eec5cc 100644
--- a/vdagent/file_xfer.cpp
+++ b/vdagent/file_xfer.cpp
@@ -46,6 +46,7 @@ void FileXfer::handle_start(VDAgentFileXferStartMessage* start,
     uint64_t file_size;
     HANDLE handle;
     AsUser as_user;
+    int wlen;
 
     status->id = start->id;
     status->result = VD_AGENT_FILE_XFER_STATUS_ERROR;
@@ -81,7 +82,18 @@ void FileXfer::handle_start(VDAgentFileXferStartMessage* start,
 
     strcat(file_path, "\\");
     strcat(file_path, file_name);
-    handle = CreateFileA(file_path, GENERIC_WRITE, 0, NULL, CREATE_NEW, 0, NULL);
+    if((wlen = MultiByteToWideChar(CP_UTF8, 0, file_path, -1, NULL, 0)) == 0){
+        vd_printf("failed getting WideChar length of %s", file_path);
+        return;
+    }
+    TCHAR *wfile_path = new TCHAR[wlen];
+    if (MultiByteToWideChar(CP_UTF8, 0, file_path, -1, wfile_path, wlen) == 0){
+        vd_printf("failed converting file_path:%s to WindChar", file_path);
+        delete[] wfile_path;
+        return;
+    }
+    handle = CreateFile(wfile_path, GENERIC_WRITE, 0, NULL, CREATE_NEW, 0, NULL);
+    delete[] wfile_path;
     if (handle == INVALID_HANDLE_VALUE) {
         vd_printf("failed creating %s %lu", file_path, GetLastError());
         return;