It seems like verclsid.exe hangs on our class IDs when invoked
through explorer.exe for 5-10 seconds. It doesn't hang if I
invoke the same command line from cmd.exe, so there could be some
process parameters that don't play well with our extra thread
or to the pipe connection that we do in it.
Delay creating the RemotePathChecker thread until the first
IsMemberOf call. verclsid.exe only seems to instantiate a object
of each registered class, without actually using them, so we
can use this as a workaround.
This should be fixing issue #2680.
* Fix various spaces vs tabs issues
* Rewrite
- to use instance variables consistently
- to not make shared state explicit instead of relying on
class variables of a common base
* Fix reconnecting to an oC client.
Occasionally on Windows ~DiscoveryMainThread() triggered a crash.
Probably because the QMutableLinkedListIterator was destroyed after
it's underlying data had been removed (from the map).
Cleaning up the map and lists was redundant anyway, so the
destructor is changed to only explicitly destroy the vio_file_stat
objects.
The _listeners list is destroyed before the _localServer.
And since _localServer is the parent of all generated QLocalSockets,
they get destroyed in turn - which triggers onLostConnection() and
thus accessed the destroyed _listeners list.
To avoid that, delete all active QLocalSockets in SocketApi before
its members are destructed.
We also now delete sockets when we're done with them. I think
disconnected sockets would otherwise linger until SocketApi destruction.
It make jenkins fail with the error:
CMake Error at CMakeLists.txt:3 (cmake_policy):
Policy "CMP0020" is not known to this version of CMake.
This reverts commit 6d380c8548.
Usefull when the folder does not exist (for example in case the theme
has a defaultServerFolder that does not yet exist, #2788)
But also to avoid confusion (issue #2663)
This crash was uncovered when testing parallel chunks when one chunk
finished the upload. The propagate was then finished with the other
UploadDevices still being in-flight in the QNAM.
There could be a race condition if the file was updated on the server
between the discovery and the propagate phase. By taking the mtime from
the server, we make sure that we do not have a race.
This is tested by t6.pl with BIG3.file because the script was modifying
the file between the two phases
