Computer 1
Computer 2
WDCloud
Using realtime sync,
1. If I delete a file from comp1, it syncs and removes the file from the wdcloud local storage drive.
2. Comp2 does a realtime sync, then it sees the file is missing from the cloud and uploads the file from its c drive to the cloud.
3. Comp1 does a realtime sync, sees the file on the cloud, but it isn't on the c drive. RTS removes the file from the cloud.
4. Go to Step 2.
Never ending loop. No idea what will happen when I introduce a 3rd computer!!
Also, they will only sync when I'm connected to my home network - Not 100% knowing how the WDCloud system works, doe the local wdcloud sync to a real cloud storage on the internet? Not a major issue but good to know.
Ultimately I'm trying to get round not having to pay a large dropbox subscription. Any advice on the settings to avoid the never ending loop described above please?
Thanks in advance team.
Multi Computer & WDCloud Sync
- Posts: 1
- Joined: 20 Nov 2017
-
- Posts: 8
- Joined: 22 Nov 2017
Hi,
it seems to be a general problem using more than one PC or BackUpDevice.
Zenju, sorry maybe I m totally wrong, but i try to give my explanation.
I suppose FFS keeps trace of the LAST sync activity (I suppose creating a sort of list for all objects/timestamp in the directory - sync.ffs_db) and uses it in the NEXT sync identifying the difference; at the end FFS updates again the object/timestamp list.
That explains the reason because executing on a third node, FFS is not able to understand what happened to some objects. It is really evident for deletions.
Zenju, sorry again I take the liberty to suggest a solution ...
If the object/timestamp lists are indexed by a physical id for the couple of devices (e.g.: PC1 and BU1), changing one of two (e.g.: PC2 and BU1) another different list will be used, avoiding the problem.
But in this solution there are a couple of remarks:
1. Programatically identification (maybe physical) of devices, in order to create a unique id for the list;
2. Management of these ids (in case a device will no more used or substituted); maybe a re-sync option or the possibility to associate to these ids a description, so the user can control and eventually remove unused lists.
I hope writing this post I didnt violate any rule.
Anyway FFS is really GREAT and I m really thankful for your job, compliments!
it seems to be a general problem using more than one PC or BackUpDevice.
Zenju, sorry maybe I m totally wrong, but i try to give my explanation.
I suppose FFS keeps trace of the LAST sync activity (I suppose creating a sort of list for all objects/timestamp in the directory - sync.ffs_db) and uses it in the NEXT sync identifying the difference; at the end FFS updates again the object/timestamp list.
That explains the reason because executing on a third node, FFS is not able to understand what happened to some objects. It is really evident for deletions.
Zenju, sorry again I take the liberty to suggest a solution ...
If the object/timestamp lists are indexed by a physical id for the couple of devices (e.g.: PC1 and BU1), changing one of two (e.g.: PC2 and BU1) another different list will be used, avoiding the problem.
But in this solution there are a couple of remarks:
1. Programatically identification (maybe physical) of devices, in order to create a unique id for the list;
2. Management of these ids (in case a device will no more used or substituted); maybe a re-sync option or the possibility to associate to these ids a description, so the user can control and eventually remove unused lists.
I hope writing this post I didnt violate any rule.
Anyway FFS is really GREAT and I m really thankful for your job, compliments!
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
This sounds more like a setup/configuration issue rather than a fundamental problem with RTS. But it's probably not possible to solve this without going into details.
