Dry run results?

[henrivdm]

Hi all, newbie trying to figure out Rclone on Linux Mint on a bid to get off Win10, so please be gentle.
I have created a Onedrive remote, copied files, synched manually pc-to-pc, now want to set up the BiSync Onedrive-to-pc.
I have run the Dry Run with Resync to assess whether everything look right (with a couple of deliberate test changes on Onedrive), but for the life of me cannot see a neat list of Changes proposed from the Dry Run. Is this feature available (I would think it should be a pretty obvious outcome of a Dry Run to list changes?
Transfer Activity is a long long list of 'checked' seemingly with no way to filter for changes? Help please!

[henrivdm]

(PS one of the best bits of software that came out of Microsoft Powertoys was a Synch tool I used for years which perfectly reported all changes prior to executing them - this is the sort of feature I am looking for....)

[Hakanbaban53]

Hi @henrivdm,

Welcome to Linux Mint and to RClone Manager! Coming from Windows tools like Microsoft SyncToy (PowerToys SyncToy), wanting a clean diff preview before executing a bidirectional sync is completely natural.

Here is what is happening under the hood and where you can see those proposed changes right now:

Why is Transfer Activity full of "Checked"?

When Rclone runs a sync or bisync, it evaluates every single file on both paths:

• Files that are identical on both sides are marked as Checked (with checked: true).
• Files that have differences and would be transferred during a --dry-run are reported as transfers (with checked: false, and logged by Rclone with NOTICE: <file>: Skipped copy as --dry-run is set).

Because Rclone's background statistics stream reports both checked files and actual transfers, a dry run on a folder with thousands of files generates a long list of Checked rows in the Transfer Activity panel, which understandably makes finding the few actual changes hard to spot.

Where can you see the dry-run changes right now?

1. Job Details / Logs:
   In the completed Bisync Job details (under your Job/Task Logs modal), Rclone returns the direct engine output summary. Look inside the result output—it explicitly lists the proposed actions, for example:

   NOTICE: - Path1 Resync is copying files to - Path2
   NOTICE: my_test_file.docx: Skipped copy as --dry-run is set (size 1.2Mi)
   

2. Dedicated "Check" Feature (SyncToy-like Diff):
   If your primary goal is to compare two remotes/folders and see a report of identical vs missing vs changed files, Rclone Manager has a dedicated Check action (powered by Rclone's operations/check). It provides a categorized table showing:
   • Matches (identical)
   • Differences
   • Only on Path 1
   • Only on Path 2

Upcoming UX Improvements

You raised a great usability point! We are currently working on improvements to make dry-runs much more convenient:

1. Transfer Activity Quick Filters: Adding status filter pills (e.g. All, Changes Only, Errors) so you can instantly hide all Checked files with one click and see only the files that would be modified or transferred.
2. Bisync Dry-Run Summary in Job Details: Formatting the raw bisync output in the Job Details dialog so the dry-run results and skipped file list are highlighted front and center.

Thank you for the valuable feedback, and please feel free to reach out if you have any questions while setting up your remotes!

[henrivdm]

Thanks very much @Hakanbaban53 I will have a look.
Does the Bisync perpetuate file moves (and deletes for that matter) in both directions, or will file moves from say Folder A to Folder B on the host show the files as missing in Folder A and want to copy them back from the destination?

[Hakanbaban53]

Yes, Bisync propagates moves and deletes in both directions.

For example, if you move "Folder A/file.txt" to "Folder B/file.txt" on the host, Bisync will see that "Folder A/file.txt" was deleted and that "Folder B/file.txt" was added. On the next successful bisync, those changes are propagated to the other side.

So it should not see the missing file in Folder A and simply copy the old remote copy back. Bisync keeps listings/state from the previous run specifically so it can distinguish a deletion from a file that only exists on one side.

One small distinction is that Bisync doesn't really track a "move" as an atomic move operation. From its point of view it's generally a delete at the old path + a new file at the new path, and it synchronizes those changes accordingly.

Conflicts or interrupted/invalid Bisync state can complicate this, of course, which is why the stored Bisync listings are important.