I can't see this discussed before so hope you can help me please...
I am using latest RealTimeSync to two-way sync a laptop with a UNC path to a desktop.
I get the "Warning: Recycle Bin is not available for the following paths! Files will be deleted permanently instead" for the UNC path which I understand.
So I thought I would use Versioning with the Replace option. But I would want files to be deleted on the laptop to be versioned on the laptop, and files to be deleted on the desktop to be versioned on the desktop. Assuming that FFS issues a Rename/Move command rather than reading the file to be deleted over the network link & writing it back under it's new location/name?
But the synchronisation settings only allow me to select a single versioning folder specific to either the laptop or the desktop.
Is there any way to specify a versioning folder for both sides please?
Versioning folder for both sides
- Posts: 19
- Joined: 5 Nov 2010
-
- Posts: 2308
- Joined: 22 Aug 2012
It seems you misunderstand the concept here.
Syncing serves to have identical file-state on either/each side/site.
In synchronized state, there is no difference.
When using versioning, if a newer version of that file exists FFS saves the previously synchronized version of that file to the versioning location and in the synced location still containing the previous version, replaces that previous version by the new version as the synchronized file.
The previous version is still relevant to both sides; either side might want to revert to, or at least open, a previous version, not just the source or non-source side of the newer version.
Hence, it makes all the sense in the world to store previous versions in one arbitrary, "central" location, rather than disperse previous versions over two (or more) locations.
Plerry
Plerry
Syncing serves to have identical file-state on either/each side/site.
In synchronized state, there is no difference.
When using versioning, if a newer version of that file exists FFS saves the previously synchronized version of that file to the versioning location and in the synced location still containing the previous version, replaces that previous version by the new version as the synchronized file.
The previous version is still relevant to both sides; either side might want to revert to, or at least open, a previous version, not just the source or non-source side of the newer version.
Hence, it makes all the sense in the world to store previous versions in one arbitrary, "central" location, rather than disperse previous versions over two (or more) locations.
Plerry
Plerry
- Posts: 19
- Joined: 5 Nov 2010
I think I may have misunderstand the concept. I agree syncing serves to have identical file-state on either/each side/site. I am only trying to find an alternate solution for the fact the Recycle Bin is not available on one side.
FFS (via RTS) is running on multiple laptops, syncing to the same desktop PC.
If sync replaces or deletes a file on the laptop, I am assuming the previous version of the file gets put in the laptop's Recycle Bin.
If sync replaces or deletes a file on the desktop, the replaced/deleted file is permanently deleted as FFS cannot use the Recycle Bin when using UNC paths.
If I now configure versioning to address no Recycle Bin for the desktop, the Recycle Bin on the laptop also won't get used.
If I create the versioning folder on the laptop, any files to be replaced/deleted on the desktop will the sent over the network (only the desktop has the previous version of the file). If I create the versioning folder on the desktop, any files to be replaced/deleted on the laptop will be sent over the network.
I'm potentially doubling my network traffic and I have to set up another share for the user to get access to the versioning folder from either side.
As I say I'm only trying to avoid permanent deletions that would only apply to the UNC path side.
Am I missing something?
FFS (via RTS) is running on multiple laptops, syncing to the same desktop PC.
If sync replaces or deletes a file on the laptop, I am assuming the previous version of the file gets put in the laptop's Recycle Bin.
If sync replaces or deletes a file on the desktop, the replaced/deleted file is permanently deleted as FFS cannot use the Recycle Bin when using UNC paths.
If I now configure versioning to address no Recycle Bin for the desktop, the Recycle Bin on the laptop also won't get used.
If I create the versioning folder on the laptop, any files to be replaced/deleted on the desktop will the sent over the network (only the desktop has the previous version of the file). If I create the versioning folder on the desktop, any files to be replaced/deleted on the laptop will be sent over the network.
I'm potentially doubling my network traffic and I have to set up another share for the user to get access to the versioning folder from either side.
As I say I'm only trying to avoid permanent deletions that would only apply to the UNC path side.
Am I missing something?
-
- Posts: 2308
- Joined: 22 Aug 2012
As you sync multiple laptops to the same desktop (assuming in the same synced-state location on that
desktop PC), it is by far the smartest choice to also define your previous-version location on that
desktop PC (identical for all laptop syncs).
If, during a sync, a laptop contains a newer file-version than the desktop's synced-state location,
the desktop file will be renamed (adding the timestamp) and moved on the desktop from the synced-state
location to the previous version location.
Only the newer file-version will be sent over the network from the laptop to the synced-state location
on the desktop.
If,during a sync, the desktop's synced-state location contains a newer file-version than the laptop,
this must be the result of a previous sync (with the exception mentioned below).
During that previous sync, the newer file was uploaded/copied to the synced-state location after the
previous version in the synced-state location was renamed and moved to the previous-version location.
Hence, for the present sync the previous version at stake already exists in the previous-version location
and does not need to be copied or moved from the laptop to the desktop.
Obviously, the newer file-version still will be copied over the network from the desktop's synced-state
location to the laptop .
In either of the two above cases, the previous version does not need to be sent over the network.
Exception:
If the newer file version in the desktop's synced-state location is not the result of a previous sync,
but e.g. from having been edited on the desktop in the synced-state location, no previous-version
exists in the previous-versions location. In that case, only during the first sync with any of the laptops
the previous version needs to be sent from the laptop to the previous versions location over the network.
For any consecutive syncs with any other laptop, the previous version already exists and does not
need to be sent.
Obviously, during the first sync with each of the laptops, the newer version will be sent from the desktop
to the laptop.
Note: Using the synced-state location on the desktop as the desktop's working location is not recommended.
If files also need to be edited on the desktop, it is far better to create a separate working location
on the desktop, and (locally) sync that working location on the desktop with the synced-state location
on the desktop, just like you do for the laptop(s). This also prevents said exception.
Plerry
desktop PC), it is by far the smartest choice to also define your previous-version location on that
desktop PC (identical for all laptop syncs).
If, during a sync, a laptop contains a newer file-version than the desktop's synced-state location,
the desktop file will be renamed (adding the timestamp) and moved on the desktop from the synced-state
location to the previous version location.
Only the newer file-version will be sent over the network from the laptop to the synced-state location
on the desktop.
If,during a sync, the desktop's synced-state location contains a newer file-version than the laptop,
this must be the result of a previous sync (with the exception mentioned below).
During that previous sync, the newer file was uploaded/copied to the synced-state location after the
previous version in the synced-state location was renamed and moved to the previous-version location.
Hence, for the present sync the previous version at stake already exists in the previous-version location
and does not need to be copied or moved from the laptop to the desktop.
Obviously, the newer file-version still will be copied over the network from the desktop's synced-state
location to the laptop .
In either of the two above cases, the previous version does not need to be sent over the network.
Exception:
If the newer file version in the desktop's synced-state location is not the result of a previous sync,
but e.g. from having been edited on the desktop in the synced-state location, no previous-version
exists in the previous-versions location. In that case, only during the first sync with any of the laptops
the previous version needs to be sent from the laptop to the previous versions location over the network.
For any consecutive syncs with any other laptop, the previous version already exists and does not
need to be sent.
Obviously, during the first sync with each of the laptops, the newer version will be sent from the desktop
to the laptop.
Note: Using the synced-state location on the desktop as the desktop's working location is not recommended.
If files also need to be edited on the desktop, it is far better to create a separate working location
on the desktop, and (locally) sync that working location on the desktop with the synced-state location
on the desktop, just like you do for the laptop(s). This also prevents said exception.
Plerry
- Posts: 19
- Joined: 5 Nov 2010
Thanks for your comprehensive explanation Plerry.
It is exactly the "edited on the desktop in the synced-state location" that breaks the elegance of using this solution.
I am synchronising user profile folders My Documents, My Music, My Pictures etc to the desktop.
Not only does that serve as a backup (from which I also take offsite backups) it allows the user to use the desktop if they can't be bothered to get their laptop out.
Having separate working locations would be an added complexity (not sure how I would sync multiple user profiles elegantly on the desktop) for something which is working well apart from the Recycle Bin not being available over a UNC path.
User is directly editing files in the synced-state location on the laptop so can't see why that wouldn't be recommended for the desktop (apart from this versioning issue).
I'm still wanting a versioning folder on both sides (replace functionality would suffice).
It is exactly the "edited on the desktop in the synced-state location" that breaks the elegance of using this solution.
I am synchronising user profile folders My Documents, My Music, My Pictures etc to the desktop.
Not only does that serve as a backup (from which I also take offsite backups) it allows the user to use the desktop if they can't be bothered to get their laptop out.
Having separate working locations would be an added complexity (not sure how I would sync multiple user profiles elegantly on the desktop) for something which is working well apart from the Recycle Bin not being available over a UNC path.
User is directly editing files in the synced-state location on the laptop so can't see why that wouldn't be recommended for the desktop (apart from this versioning issue).
I'm still wanting a versioning folder on both sides (replace functionality would suffice).
- Posts: 19
- Joined: 5 Nov 2010
So for the time being I thought I would suppress the recycle bin warning so my log monitoring program doesn't get triggered.
I set WarnRecycleBinNotAvailable to false in GlobalSettings.xml but FFS still reports the recycle bin is not available. Arrggghhhh!
I'll have to go through all my sync jobs and set DeletionPolicy to Permanent.
I set WarnRecycleBinNotAvailable to false in GlobalSettings.xml but FFS still reports the recycle bin is not available. Arrggghhhh!
I'll have to go through all my sync jobs and set DeletionPolicy to Permanent.
