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!
> 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).
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*?
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"
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?
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.
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
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.
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.
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.
alejbox, 01 Nov 2022, 13:10
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
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
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!
Even today the problem of the incompatibility presented by 2flow2 (25 oct 2022, 01:58) persists in RTS, especially in Linux Ubuntu 24.04.1, which is the version I'm using.
And this specific solution is functional only in cases where folder pairs point to a unidirectional action, that is, where changes should only occur in Ubuntu folders and not google drive (as in a backup, for example). In cases of synchronization, where at least one or all Google Drive folders, the pairs of folders in question, need to be monitored because they undergo some kind of change (file creation, updating, or deleting), these folders would need to record RTS monitoring, and RTS should necessarily support this monitoring on Google Drive folders, just as FFS does.
Even FFS has progressed greatly in terms of external network support, especially regarding Google Drive, resolving all previously verified problems.
Current problem:
Realizing that FFS today allows the inclusion of gdrive folders on one or 2 sides of the pair of folders, through a special service, and that RTS does not support, I changed (still in Ubuntu) the reference of this service, for RTS, for example:
From: GDRIVE:/(User Account on Google)/(Folder Way)
By: /run/user/1000/gvfs/google-drive:host=gmail.com,user=(user of Google, without '@gmail.com')/(Folder Way*)
* Noting that this path and folder name is found on the GDRIVE server itself, and that this reference I could find easily using the "search" button next to the respective folder reference in RTS.
With this exchange, when activating the RTS service, the "Start" button, the RTS shows its icon in the notification bar, but simply wages in memory and does absolutely nothing, even preventing access to the menu of this notification bar icon, as well as removing it (aborts it) from memory.
Conclusion: The problem in RTS persists and is unfortunate, as FFS has progressed and RTS has remained unchanged over the years.
However, in Windows this problem today was completely resolved, because the New Google Drive app (which in 2018 had other properties), assembles the drive of an account, through a logical unit (eg "g:"), so in RTS, the reference to these folders can be treated as if it were an external device, like a pen drive. And in the meantime, RTS works perfectly.
Conclusion, I get the solution proposed by ADG (31 OCT 2022, 12:44), at Linux Ubuntu; "On Linux: Schedule .FFS_Batch in the 'Crontab' to Run Every X Minutes". Only plausible solution.
Grateful for everyone's attention and I hope I helped.
