Skip to content
This repository has been archived by the owner on Jul 26, 2022. It is now read-only.

Feature_Request: Selective down sync #575

Open
DonEstefan opened this issue Apr 8, 2016 · 0 comments
Open

Feature_Request: Selective down sync #575

DonEstefan opened this issue Apr 8, 2016 · 0 comments

Comments

@DonEstefan
Copy link

Hi,

I have a a notebook with lots of disk space. I use syncancy to upload my media folders to a webdav server. Syncancy does a great job for this :)

I also have a tablet. Due to a lack of diskspace, I'd like to sync only a subset of the media folders from the webdav server to this device (I think dropbox has a similar "selective sync" feature for folders).

I have tried to simulate a selective sync like this:
sy connect syncancy:/...
sy down --no-apply (fetch the List of available files without syncing any files yet)
sy ls --recursive (show the list of available files)
sy restore <file_id1> -r ... (download a selected file)
sy restore <file_id2> -r ... (download a selected file)
...

This is possible, but not very convenient (the filename suffix added by sy restore is a real pain in this case ;) ). And it works only on files that have been changed. It seems like sy restore works only if the file has a version history. And the version history seems to be created only after a file was changed at least once.
This procedure is OK to get in sync once and if you have only a few files. But it is a real hassle if you want to stay in sync over time or with multiple files.

What I'd like propose, is a filter list similar to the .syignore file.
But while .syignore prevents files from being uploaded, the new filter file should prevent folders from being downloaded.
The existence of the download filter file should set the syncancy folder into "selective-sync mode", where the --no-delete option for sy watch, sy up and sy status is forcefully enabled. This way you won't delete any data on the remote server on the next run of sy up

If this would be implemented, then there would be no more need to "abuse" sy restore like in the example above.

Further considerations

  • sy connect should be able to enable the new "selective-sync mode" for the local folder during initialization by adding all folders of the remote repository to the local download filter file (to prevent a first full download). It probably needs to do an inital sy down --no-apply to be able to do that (fetch the file/folder list of the remote repository).
  • when in "selective-sync mode" sy down would need a new option --folder <folder-id> to remove the given folder from the download filter list before the actual sy down starts. This would enable permanent sync for the given folder.
  • when a local folder is deleted, then syncancy should automatically add the folder name to the download filter file (so it won't re-appear on the next run of sy down). Of cause only when syncancy runs in "selective-sync mode" (=a download filter file exists)
  • there should be another option to define if new folders appearing on the remote repository should automatically be added to the download filter list or not.
  • sy ls -r -t d should be enhanced to reflect if a folder in the remote repository is in the download filter list or not (column with + or -)
  • "selective-sync mode" should be a local setting for the local folder. It should not be synced to the remote repository, so other instances of syncancy can still use normal operation mode with the same remote repository.
  • there is some risk when the download filter list is deleted by accident. Since this will disable "selective-sync mode" and thus no longer enforce --no-delete, you will end up with a huge download (on the next sy down ) or with deleted folders on the remote repository (on the next sy up). It might be a good idea to protect the filter list from manual editing or accidential deleting (however that may be achieved).

What do you think of this?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant