-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2 way sync? #4
Comments
It's a unidirectional sync. There's been an outstanding TODO to watch the remote server, but it seems most of the central need of this is served by the current unidirectional method. It might be cool to add a command-line option like "--bidrectional" as well as "--pull" or whatever to enable these sorts of features. Is there a need for that? |
I do perhaps have a need for it. Although, there may be an existing solution. I am looking to build a mechanism to transfer files automagically from a networked file server to a webdav server on my phone whenever my phone is on the same network as the server. Perhaps I could use just a webdev client on the file server to push files to the phone's webdav server. However, I can't remember why this library was so appealing to me. I think it was because I was thinking about browserifying it for phonegap, but then I realized curl was a requirement. I honestly haven't thought it all through as I've been pretty slammed over the past few weeks and this is for a personal project of mine. All in all, please don't spend your time on it if I'm the only use case. 😄 |
It's an interesting idea nontheless. A pull-only component could be very useful for most of our users. The network polling to file watch the remote server is the only "possibly hairy" component I can think of. It could then achieve your goal of polling the network once you're online and pulling from the server once it finds a safe connection. Thats kind of how webdav-sync works now, it just dumbly pushes the file and if it transfers then fine, if it fails then fine, otherwise it tries again the next time the file changes. Yes we're currently dependent on curl but that dependency could be replaced relatively simply, it hasn't caused too many headaches for users yet. So if it ain't broke, don't fix it. A browser-based webdav client similar to this one SHOULD be possible I suppose, I'm sure at some point I've seen things like Greasemonkey scripts built to push or pull all of a webdav directory. Anyway, I'll put it on the list of big next TODOs for a minor release. |
A bi-directional sync sounds scary. From an implementation point of view extra care and testing should be added to avoid race conditions. It would also require some sort of "optimistic locking" either via version numbers and checksums on custom headers/properties or a poor-mans version that keeps "last modification" times in sync, accounting for offsets of the remote and local machine in order to avoid loosing local code by accident. I wouldn't enable this without keeping copies of the local files before updating them. Network wise polling each one of the files on the remote instance can be pretty slow. I would probably involve using webdav's PROPFIND extensively to get listings, lock status.... As for replacing curl, that shouldn't be too hard but probably unnecessary. I doubt webdav authentication and PUT requests would work transparently on a browser environment when browserifying them. Even if it's possible, they would probably require pulling in crypto and gzip which would increase file size prohibitively. |
Is it possible to use this package to just send stuff one-way? Like just client -> server? As it stands now, what happens if I have an empty local directory and sync it with a directory on the server that is full of files? Will it populate the local with the files from the server or will it delete the files on the server to match the local directory? |
Yes Jakobud: this is built just for that kind of usage. As it stands now, your empty directory would not do anything to that remote directory except push new files you add to it or push changes to those files (including deletes of those files, that would be the only instance where it would remove a remote file or directory). webdav-sync pushes any ongoing changes from your directory up to that remote directory. It does not "clean" the remote directory when starting, it only pushes changes that occur while webdav-sync runs in the background. It does not do "pull sync", meaning it does not make any changes to local files ever. If files are changed remotely, it will not (currently) watch those files or poll those directories and pull down new changes, or delete local files or directories. This kind of "pull-sync" is a feature we're interested in adding in the future (though it would be tricky, see bermi's reply above), we'd love to see Pull requests to implement it. It seems to be a surprisingly rare use-case for WebDAV usage. Most people just want to push up ongoing changes from a directory, and webdav-sync was originally built for just that purpose. |
Is this syncing files both ways? Local->remote and remote->local? Or is it unidirectional?
The text was updated successfully, but these errors were encountered: