RealTimeSync will not mirror to Google Drive?

[2Flow2]

Hey there!
As I understand it, a Google Drive location cannot be monitored for changes to trigger RealTimeSync, but a local Windows drive CAN be monitored for changes, which can trigger RealTimeSync to copy changes over to Google Drive.

So I have a fairly simple .ffs_batch file, shown below:


All locations are pulling FROM my local C:\ drive and are one-way mirroring TO my cloud Google Drive.

This file seems to run fine when I manually trigger it in FreeFileSync, but as soon as I load it into RealTimeSync (https://imgur.com/a/37dVldv), I receive the error message:

The gdrive protocol does not support directory monitoring


Can anyone tell me what I am doing wrong, or what the issue is?
Thanks!

[Plerry]

> All locations are pulling FROM my local C:\ drive and are one-way mirroring TO my cloud Google Drive.

So there is no need to monitor the gdrive folders for changes, as all changes are initiated on your C drive.
Simply delete all gdrive locations from the list of Folders To Watch in the RTS gui (via the "-" icon in front).

[2Flow2]

Ah, excellent, that worked when removing them from the GUI!

However, I am running this as a batch job that is auto-starting via a command line entry with the ".ffs_batch" file set as an option. So because I have to manually click the "-" icon on the RTS GUI, it is not able to be start itself automatically.

How do I edit the .ffs_batch file itself to remove those gdrive locations from being monitored while still indicating that is where I want to copy changes *TO*?

Thanks!

[Plerry]

Simply create the RTS job in the RTS GUI by dragging the *.ffs_batch configuration into the RTS GUI (as you show above), then remove the gdrive locations from the list of Folders To Watch, and then save that RTS configuration as a *.ffs_real-file via the RTS GUI File menu (top-left) under a self-selected name.

Then autostart RTS (e.g via command-line), specifying the *.ffs_real configuration rather than the *.ffs_batch configuration.
Command-line for autostarting the correct RTS configuration (example):
"C:\Program Files\FreeFileSync\RealTimeSync.exe" "D:\Backup Projects.ffs_real"
See also here.

Note that the command-line inside the RTS GUI should still invoke FFS and open the relevant *.ffs_batch sync configuration (not the *.ffs_real-file).
Command-line as inside the RTS GUI (example):
"C:\Program Files\FreeFileSync\FreeFileSync.exe" "D:\Backup Projects.ffs_batch"

[2Flow2]

Oh, yes, that seemed to work perfectly! Thank you so much for all the help!

I just have one question left that is out of curiousity and not an "issue" now:
When you drag a .ffs_batch file containing a mirror job into RealTimeSync and it auto-populates the GUI, why does it autopopulate the file destinations as file locations to monitor? What is the purpose or benefit of having it add the mirror locations as 'locations to monitor' if we *don't* want to monitor them?

[xCSxXenon]

Some people may want to monitor them. For example, I am mirroring a source folder to a location accessible by many different people. Someone may accidentally make a change on pricing guide, or instead of making a copy of a template, they overwrite the template with a document containing all of their info instead. The proper way to do this would be to make the file/location have proper permissions, but sometimes you don't have access to that option. By monitoring the destination, if someone modifies/deletes a file that they aren't supposed to, RTS will see that change and run a mirror from my local folder to the network location and "reverting" the change.

[acg]

ffs is not monitoring software (like gdrive, pcloud, mega, etc. clients), however there is a workaround:
- On linux: schedule .ffs_batch in the "crontab" to run every x minutes
- On windows: schedule .ffs_batch in "task scheduler" to run every x minutes
PS: in both cases it needs to be run in command line with no GUI (or minimized with no visible windows), so that it doesn't interrupt the work of other GUI processes
PS: There must be other better ways to do it. Hopefully one day ffs will become a sync client software, similar to the clients already mentioned

[Plerry]

The reply of xCSXenon above even indicates a benefit of (by default) adding all base-locations in a sync configuration to the RTS list of Folders To Watch.

The only one who can tell for sure is Zenju, but personally I believe that this approach was simply the quickest and easiest way to make RTS "match" the drag&dropped or specified FFS sync configuration.
By simply adding all base-locations to the RTS list of Folders To Watch, there is no need to have RTS analyze the exact FFS sync variant. Additionally, this makes it much easier to maintain RTS as a separate tool, as it minimizes the dependencies.

[acg]

Honestly, My unfinished business is RealTimeSync. I've read the documentation and couldn't find anything useful that FreeFileSync doesn't do. If someone could explain to me what RealTimeSync does that FreeFileSync can't do, I'd be grateful.

[xCSxXenon]

Honestly, My unfinished business is RealTimeSync. I've read the documentation and couldn't find anything useful that FreeFileSync doesn't do. If someone could explain to me what RealTimeSync does that FreeFileSync can't do, I'd be grateful.

RTS monitors locations and runs a command when changes are detected. There is nothing that one can do that you can do in the other

[acg]

The message:

The gdrive protocol does not support directory monitoring


It only appears on windows (tested on windows 10). It doesn't show up on linux (tested on ubuntu 22.04).
But from what I have tried, this message appears in windows because the command line is misconfigured.
I had not tried RTS. It is the best. In my case I use bidirectional linux and batch and since there is no official google drive client for linux I will start using RTS instead. It's perfect

[2Flow2]

Ah, xCSxXenon's explanation made perfect sense! So when RTS adds the destination folders to the list of folders to be monitored, it still triggers a mirror of the source location to the destination location. That makes perfect sense, and the example provided is excellent for helping conceive of when this would be useful! Thank you for all the help, everyone!