Report Full Paths in Logs

I would like rClone to report full, root-relative paths in log messages. I know this isn't an existing option, so I've been digging through the source.


Where are the absolute paths truncated for logging (specifically for the "object" field in JSON logs)? Where should I be looking in the source? Thanks!


Suppose I run:

rclone copy /path/to/local/folder some:remote

rClone's logs will report paths like this:


My goal is have those paths reported as:


I think the confusion would be rclone doesn't work like rsync so having a relative path would make more sense as you can match A to B when you do operations.

So if you do /path/to/local/folder to some:remote, that translates to a relative mapping to make A to B.

Not sure where in the source code offhand but I think that's the reason.

Oh, I see why rClone defaults to reporting relative paths. That’s the right default.

For my case, though, having the full path reported in the output would be very useful. I’m just not sure where to begin making that change in the source.

Rclone never uses absolute paths!

The paths are always relative to the root of a backend.

So if you are doing

rclone copy drive:folder /path/to/folder

Then rclone creates a backend drive: with a root of folder and a backend local with a root of /path/to/folder and uses paths relative to those two roots.

It doesn't really make sense for rclone to log absolute paths as when it is copying from A to B the relative paths to the root are the only thing that matters.

It isn't straight forward to add absolute paths to all logging as rclone doesn't use them. Probably the best thing you could do would be to modify the local backend - modify this function to return the full path and then at least local backend paths would print out in full

I guess the /path/to/local/folder is passed to rclone from a variable/constant in your own app.

Why do you consider it easier/better to change the code in rclone than doing a string concatenation in you own code/app?

@ncw Thank you!

@ole It’s more performant. And since I’m already maintaining a custom fork to tweak the logging output, it’s not much added overhead.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.