A literal constant is used for error type as the project is not
dependent on glib2 and that Visual Studio and CMake are supported
so it would make the compilation on some environment more complicated
than actually is just for a constant.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Kevin Pouget <kpouget@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
When building with older mingw, sprintf_s does not
always work as expected, but snprintf does.
Also it's more consistent in the file.
Note that when building with VS, snprintf becomes sprintf_s
Related: rhbz#1410181
Signed-off-by: Uri Lublin <uril@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Have the same behaviour of Linux machines.
The directory is not opened again and again, only is not already
opened.
This is done checking the directory opened in explorer.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Limit too much manual work.
By default delete the file, unless success() is called.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Some characters are reserved and should not be used in Windows
independently by the file system used.
This avoid to use paths in the filename which could lead to some
nasty hacks (like names like "..\hack.txt").
The return statement cause the file transfer to be aborted with
VD_AGENT_FILE_XFER_STATUS_ERROR as status.
":" is used to separate filenames from stream names and can be used
to create hidden streams. Also is used for drive separator (A:)
or device names (NUL:).
"/" and "\" are reserved for components (directory, filename, drive,
share, server) separators.
"*" and "?" are wildcards (which on Windows are supported by
different APIs too).
"<", ">", """ and "|" are reserved for shell usage.
More information on "Naming Files, Paths, and Namespaces" page at
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
This fixes also https://bugzilla.redhat.com/show_bug.cgi?id=1520393.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Previously, if the user attempted to transfer a file that had the same
name as a file that already exists on the guest, we would just fail the
transfer. This patch tries to match the behavior of the linux vdagent
where we try to append an integer onto the name of the new file to make
it unique. For example, if you tried to transfer 'file.doc' to the guest
and that file already existed, it would try to create 'file (1).doc'
instead. If that also failed, it would attempt 'file (2).doc', etc, up
to 63.
Resolves: rhbz#1410181
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Previously, when a client disconnects, the vdagent executable exited.
The agent was restarted immediately in order to be ready for the next
client to reconnect.
This is generally fine, but there are certain situations
where it causes issues. For example, if client A is connected to a guest
and client B connects to the same guest, client A will be forcibly
disconnected and causes the the vdagent to restart. This scenario is
racy because the agent can take some time to exit and restart. Client B
may think that the agent is connected at startup and may send agent
messages to the guest. At some point the server will recieve
notification that the agent has exited and send an AGENT_DISCONNECTED
message to client B. After the agent has been fully restarted, an
AGENT_CONNECTED message will be sent to the client, but any messages
sent between client connection and the AGENT_DISCONNECTED message will
be lost. This causes problems especially with fullscreen mode in
virt-viewer.
The solution is to not exit and restart the agent when a client
disconnects. This is how the linux vdagent behaves. Instead, we simply
cancel all ongoing file transfers and reset the clipboard when a client
is disconnected.
Fixes: rhbz#1064495
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Including directly shlobj.h in some MingW environment lead to some missing
definitions error. Including windows.h before fix the problem.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
This allows username to contain any extended characters (username is
embedded in the directory name).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
The 64 bit Visual Studio build complains that:
.\file_xfer.cpp(223) : warning C4244:
'=' : conversion from '__int64' to 'unsigned int', possible loss of data
As a followup of commit 462295d9f8.
Building with Visual Studio, fails as there is no inttypes.h file:
vdagent\file_xfer.cpp(21) : fatal error C1083: Cannot open
include file: 'inttypes.h': No such file or directory
This commit prevents including inttypes.h when building with Visual Studio,
and defines PRIu64 that is defined in inttypes.h for mingw compiler.
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!
Before, the target directory was a public one (for all users),
as file creation was not done with user privileges.
Now that the file is created with user privileges, it's
better to make the user desktop the target directory.
The _s functions need a recent msvcrt version, not shipped in XP by
default.
Furthermore, it appears that their sscanf_s usage was missing the extra
buffer size argument.
