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. Suited to an always-on box that mirrors a local disk into the workspace, or to a developer who wants live updates while curating a dataset.

When to monitor, and when to scan periodically

monitor does one full pass and then relies on FileSystemWatcher for everything after it. That is dependable when the files are on a local disk, where the filesystem driver delivers the change records itself.

Over a network share the records have to be generated by the server and pushed over SMB, which is best-effort: a momentary session drop invalidates the watcher, a burst of changes can overflow the kernel event buffer, and plenty of servers — Samba, consumer NAS boxes, DFS namespaces, anything fronting the storage with a second protocol — implement notification partially or not at all. An NFS mount has no notification mechanism, so the watcher never fires. None of it is reported as an error by the share: the events simply stop arriving.

The CLI does not re-create a watcher that has stopped, and it does not re-read the tree after the initial pass, so a monitor in that state keeps running and the workspace quietly drifts.

Running a sync on a schedule sets that up — the failure modes in detail, and a worked Task Scheduler example for Windows. On Linux the same shape is one systemd timer or cron entry per share.

Always give either form a UNC path rather than a mapped drive letter: a drive mapping belongs to one interactive logon and does not exist for a service or a scheduled task.

Syntax

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:

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 monitor when you need a folder kept continuously in sync, rather than the one-shot upload-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.
• Running a sync on a schedule — scheduling that one-shot instead, which is the more reliable shape on a network share.
• monitor-with-permissions — same loop, plus Active Directory ACLs.
• Data Connector — code-based alternative when files alone aren't enough.