Folder watcher waits a fixed 10 s before every sync of a local change

[digodigo]

FolderWatcher collects change events for notificationTimeoutC = 10s before it reports them (src/gui/folderwatcher.cpp). Together with the 2 s SyncEngine::minimumFileAgeForUpload this means a saved file leaves the machine at the earliest 10 s after the save, on any network.

On a 1 GbE LAN the wait dominates: 10 x 10 MB take 13.4 s, of which 10 s are waiting; with a 2 s delay the same upload takes 4.7 s (measured with a patched client against OpenCloud 7.1, macOS 26). Other clients on the same machine react within 1 to 2 s (Synology Drive, Nextcloud desktop, which uses minimumFileAgeForUpload as its only delay).

Files still being written are already handled independently of the 10 s: PropagateUploadFileCommon skips files whose mtime is younger than minimumFileAgeForUpload and schedules another sync run, and the "changed during upload" detection (FileSystem::fileChanged) triggers a re-upload. A shorter default would therefore cost an occasional repeated upload for applications that write slowly, not an inconsistent file on the server.

Discussed in #1047, where making the delay configurable was declined for support reasons. Would a lower default (e.g. 3 to 5 s) be acceptable, or a shorter delay once the change set has been quiet for a moment?

🤖 Generated with Claude Code

[TheOneRing]

Now imagine you have 100k users and we start a sync every time a file is touched.
We just gather events for 10s which is usually short enough in any context.
After the 10s are over we sync them.

So the 10s time window not only is valuable for the maintainer of large servers but also saves you some battery live.

[digodigo]

Understood, the batching matters at scale. One thought: for an isolated save the 10 s do not save a sync run, they only postpone it; batching only kicks in for events that arrive within the window. A quiet-period rule would keep the batching for bursts and still sync a single save quickly: start the sync once no new event has arrived for 2 s, but never later than 10 s after the first one. Same number of syncs for bursty writers, no wait for the common single-file case. If that is not something you want to pursue, feel free to close this.

[TheOneRing]

If one application touches 100 files in 8s the current code will trigger a single sync run.
With a timeout of 1s or without any we would run multiple syncs to sync those 100 files which all together is more inefficient.
Additionally, we might sync the same file multiple times, or prepare to sync it multiple times and abort the upload due to minimumFileAgeForUpload. But until the upload is aborted we already computed the checksum which for some files takes quite some time....