Apparently we can run our tests in parallel just fine. On my local
machine this cuts down the runtime from 3 minutes to around 50 seconds
with a parallelism of 4:
```sh
% for jobs in `seq 1 17`; do printf "--parallel %2d => " "$jobs" && time (ctest --parallel $jobs > /dev/null 2>&1); done
--parallel 1 => ( ctest --parallel $jobs > /dev/null 2>&1; ) 41.42s user 9.14s system 27% cpu 3:05.53 total
--parallel 2 => ( ctest --parallel $jobs > /dev/null 2>&1; ) 42.55s user 9.16s system 55% cpu 1:33.34 total
--parallel 3 => ( ctest --parallel $jobs > /dev/null 2>&1; ) 41.40s user 9.20s system 81% cpu 1:01.79 total
--parallel 4 => ( ctest --parallel $jobs > /dev/null 2>&1; ) 42.29s user 9.15s system 102% cpu 49.995 total
--parallel 5 => ( ctest --parallel $jobs > /dev/null 2>&1; ) 42.08s user 8.94s system 102% cpu 49.895 total
--parallel 6 => ( ctest --parallel $jobs > /dev/null 2>&1; ) 42.51s user 9.33s system 102% cpu 50.590 total
--parallel 7 => ( ctest --parallel $jobs > /dev/null 2>&1; ) 43.77s user 9.33s system 105% cpu 50.537 total
--parallel 8 => ( ctest --parallel $jobs > /dev/null 2>&1; ) 42.89s user 9.10s system 104% cpu 49.761 total
--parallel 9 => ( ctest --parallel $jobs > /dev/null 2>&1; ) 42.77s user 9.19s system 104% cpu 49.810 total
--parallel 10 => ( ctest --parallel $jobs > /dev/null 2>&1; ) 44.97s user 9.68s system 107% cpu 50.834 total
--parallel 11 => ( ctest --parallel $jobs > /dev/null 2>&1; ) 45.87s user 9.93s system 109% cpu 50.889 total
--parallel 12 => ( ctest --parallel $jobs > /dev/null 2>&1; ) 45.37s user 9.33s system 107% cpu 50.908 total
--parallel 13 => ( ctest --parallel $jobs > /dev/null 2>&1; ) 45.75s user 9.75s system 108% cpu 50.919 total
--parallel 14 => ( ctest --parallel $jobs > /dev/null 2>&1; ) 46.53s user 9.82s system 110% cpu 51.099 total
--parallel 15 => ( ctest --parallel $jobs > /dev/null 2>&1; ) 46.76s user 9.81s system 110% cpu 51.379 total
--parallel 16 => ( ctest --parallel $jobs > /dev/null 2>&1; ) 47.63s user 9.72s system 114% cpu 50.086 total
--parallel 17 => ( ctest --parallel $jobs > /dev/null 2>&1; ) 46.05s user 9.23s system 110% cpu 49.938 total
```
Let's see if this applies to the test runs in CI too.
Signed-off-by: Jyrki Gadinger <nilsding@nilsding.org>
The `ignoreFirst` bool had a short lifetime, by the time the lambda slot
handling the `LsColJob::directoryListingIterated` signal was called the
reference to that bool would report a completely different value. This
could result in the first entry of a directory listing to not be ignored
properly.
This commit changes the way the slot checks whether it's currently
iterating over the very same directory that was just requested by
comparing the request path with the path from the response.
Fixes#8915
Signed-off-by: Jyrki Gadinger <nilsding@nilsding.org>
It is a transient dependency through NextcloudFileProviderKit anyway and was conflicting with that (besides still referring to claucambra).
Signed-off-by: Iva Horn <iva.horn@nextcloud.com>
The server can respond with values like `2.58440798353E+12` instead of
a plain number like `2584407983530`.
`QVariant::toLongLong` does not recognise that as a valid number and
returns `0` instead, breaking the sync for some.
Also added a fallback value in case parsing the value as double doesn't
work either.
Fixes#8555
Signed-off-by: Jyrki Gadinger <nilsding@nilsding.org>
As per [the docs for `NSFileProviderReplicatedExtension
item(for:request:completionHandler:)`][1], the system will automatically
retry calling the method if the error is not one of `.notAuthenticated`,
`.serverUnreachable`, or `.noSuchItem`.
From my observations it seems that if the error `.cannotSynchronize` is
returned for the root container (i.e.
`NSFileProviderRootContainerItemIdentifier`), the system/file provider
framework just ends up deleting the newly created sync directory inside
`~/Library/CloudStorage`. This broke the entry in the Finder sidebar.
After changing the error to `.notAuthenticated` (which is semantically
wrong, but alas), I now could disable/enable the File Provider as often
as I wanted without the Finder sidebar entry to ever break due to the
directory having been removed previously ... Strange, this.
[1]: https://developer.apple.com/documentation/fileprovider/nsfileproviderreplicatedextension/item(for:request:completionhandler:)#Discussion
Signed-off-by: Jyrki Gadinger <nilsding@nilsding.org>
