monitor
Continuous version of upload-folder. Performs an initial sync, then watches the folder and incrementally syncs additions, modifications, and (with --fetch-server-state) deletions.
Keeps running until you stop it. Ideal for an always-on box that mirrors a network share into the workspace, or for a developer who wants live updates while curating a dataset.
Syntax
Usage: curiosity-cli monitor --server <url> --token <token> --path <dir> --fetch-server-state <bool> [options]
curiosity-cli monitor \
--server https://my-workspace.example.com/ \
--token $CURIOSITY_TOKEN \
--path /mnt/shares/docs \
--source "Shared Drive" \
--fetch-server-state true
Options
Identical to upload-folder, with the same semantics:
| Option | Description |
|---|---|
--server |
Workspace URL. Alias -s. Required. |
--token |
Library Token. Alias -t. Required. |
--path |
Folder to watch. Alias -p. Required. |
--fetch-server-state |
Required. Setting to true enables deletion sync. |
--source, --bandwidth, --upload-to, --target-uid, --extensions, --root-path, --root-folder-name, --restore-access-time, --sync-file-url, --in-place, --timeout |
Same meaning as in upload-folder. |
--username, --password, --domain |
Windows-only impersonation for folder/file reads. |
The only behavioral difference vs. upload-folder: the FileSync runs with keepInSync = true, so the process loops on a file-system watcher instead of exiting at the end of the initial pass.
Running it as a service
For production use, wrap the command in a service definition (systemd, NSSM, Windows Service) so it restarts on failure and starts on boot:
# /etc/systemd/system/curiosity-monitor.service
[Unit]
Description=Curiosity folder monitor
After=network-online.target
[Service]
Type=simple
ExecStart=/usr/bin/curiosity-cli monitor \
--server http://localhost:8080 \
--token ${CURIOSITY_TOKEN} \
--path /mnt/shares/docs \
--fetch-server-state true \
--sync-file-url true
Restart=on-failure
RestartSec=10s
Environment=CURIOSITY_TOKEN=...
[Install]
WantedBy=multi-user.target
Remarks
- Use
monitorwhen you need a folder kept continuously in sync, rather than the one-shotupload-folder. - The process runs until stopped — wrap it in a service supervisor (systemd, NSSM, Windows Service) for production so it restarts on failure and starts on boot.
- Set
--fetch-server-state true(with--sync-file-url) to propagate local deletions to the workspace.
See also
upload-folder— the one-shot equivalent.monitor-with-permissions— same loop, plus Active Directory ACLs.- Data Connector — code-based alternative when files alone aren't enough.