* commit 'a7a9d7d':
Return correct content type for /rest/events
Rename RawAPIKey -> APIKey in GUIConfiguration
Add -paths option to print config, key, database paths
Clean up error handling a bit in protocol.readMessage
Remove old reference to moved protocol
Support multiple API keys (command-line and config) (fixes#2747)
* master:
Update docs & translations
build.sh prerelease should rebuild author credits in about dialog
Use dialer in relay checks (fixes#2732)
Handle null case for invalid ng-model value (fixes#2392)
Return status code 307 instead of 302 when redirecting from HTTP to HTTPS
Benchmark for single database update
Add a CORS handler to deal with preflight OPTIONS requests
Add letiemble
Update docs and translations
Correct order of pkill(1) arguments in debian script (fixes#2728)
* master:
Update docs and translations
Model.internalScanFolder: Don't ignore special .stfolder and .stignore files.
Model.internalScanFolderSubs: Scan only requested subs.
A couple of protocol tests
Humanize serialization of version vectors (again)
FetchLatestReleases: fix the error log message
Add postinst script to restart after upgrade
Templatize Debian files
Don't require restart for usage reporting changes (fixes#2704)
RLimit comment typo
Fixes#2151.
Since Walk.walkAndHashFiles ignores .stfolder and .stignore, they will
never be found by fs.Get(protocol.LocalDeviceID, sub) in
Model.internalScanFolder. As a result, when asked to scan those subs
we end up scanning the whole folder.
This reverts the change introduced in 9b9fe0d Reduce scanning effort.
That commit caused us to automatically ignore the basename of the
specified subs and instead scan closest known root folder. For
example, in a folder that looks like:
Sync/
├── 00
│ ├── one
│ ├── three
│ └── two
├── 01
│ ├── one
│ ├── three
│ └── two
├── 02
│ ├── one
│ ├── three
│ └── two
└── one
calling '/rest/db/scan?folder=default&sub=01' called filepath.Walk on
the whole Sync/ folder instead of just the desired subfolder. This
contradicts the scan behavior promised by the documentation.
This is related to #2151.
We only need to protect the integrity of the "finders" and "caches"
slices, and for that we only need an RLock except while actually
appending to them. The actual finders and caches are concurrency safe on
their own.
