We use rclone as a tool deep down under the sandwich of datalad/git-annex/git-annex-remote-rclone, where the latter one is the one invoking rclone and already has hardcoded all command line options, so it is not the option to pass logging there... I guess what is left possibly use some env vars for the invocation if you really know that you would want those logs, e.g.
RCLONE_LOG_LEVEL=INFO RCLONE_LOG_FILE=~/.cache/rclone/logs/`date --iso-8601=seconds`.log datalad get AFILE
which seems to do the drill iff that log directory already exists, if not -- crashes.
But I wondered if I could just configure all invocations of rclone to be logged, and have log filename template allow sufficient disambiguation (e.g. by allowing {iso-8601-seconds}) and avoid collisions (e.g. by allowing {pid} for the rclone process), I would have been happy to provide in ~/.rclone.conf either a new section ([default-options] or alike) or may be even per remote specify desired logging and level -- that would have been awesome since "do once and forget but be able to introspect when needed".
WDYT?
edit: actually currently env variable specification without {pid} which is to be provided only by underlying rclone is not good enough for me since underneath we start multiple parallel git-annex-remote-rclone processes, and they all start their own rclone processes which all start to write to that single file... not quite sure if we are not loosing any records and how I could demultiplex all those records :-/
it seems that I am doomed to provision "tune up" of the RCLONE_LOG_FILE env var if specified directly in git-annex-remote-rclone and append that bash script pid to disambiguate.
Thank you for the pointer. I thumbed up and subscribed. But that issue is quite deep in the list of already thumbed up even more