Before we only had c_utf8_to_locale, but now functionality is needed to
convert a path to UNC before converting it. That does c_utf8_path_to_locale
now, while c_utf8_string_to_locale only converts the plain string, ie.
to generate wide char strings for output.
This enables the calling function to free these accordingly. That is needed
because the makeLongWinPath for efficiency reasons does not always realloc
the original string.
this fixes the error and makes complete oCC compile with GCC 5.
error: ISO C does not support '__FUNCTION__' predefined identifier
[-Wpedantic]
According to the porting guide:
The fix is either to use the standard predefined identifier __func__
(since C99), or to use the __extension__ keyword.
Also, use the mirall version for ocsync.
Currently, the csync engine part and the Qt part have different UAs,
and this makes debugging (i.e. reading access logs) difficult. On
top, we haven't increased the ocsync version number in ages. So
as a consequence, I think it would be the best to have ocsync
and the rest share the same version number, and make them identify
with the same user agent.
To ease debugging for our side, we'll still append "(csyncoC)"
for calls made by csync.
csync_reconcile.c:159:26: warning: address of array 'tmp->path' will always evaluate to 'true' [-Wpointer-bool-conversion]
if( tmp->path ) {
~~ ~~~~~^~~~
csync_file_stat_s::path is an array so it is never null
What was meant here is to check if the string was not empty
In some cryptic cases where the getetag property wasn't returned by
the server, we might be trying to c_strdup a null pointer in
csync_vio_file_stat_copy.
At least avoid crashing in this case by looking for
CSYNC_VIO_FILE_STAT_FIELDS_ETAG, like csync_vio_file_stat_destroy
does.
Windows finds DLLs using PATH or the directory of the process'
executable. By outputing those dependend DLLs together with
owncloud.exe, the developer only need to have OpenSSL's bin
and the qtkeychain build directory in his PATH to let the
dynamic linker find them.
As the documentation of RUNTIME_OUTPUT_DIRECTORY points out,
this only affects windows as other platforms don't consider
libraries as runtime targets.
