cweagans / docker-bg-sync

A container that syncs files between two configurable directories.
224 stars 39 forks source link

Only syncs once using Docker for Mac #28

Open alexromero88 opened 4 years ago

alexromero88 commented 4 years ago

The sync works nicely the first time, but after doing changes, I can see the updates in /source but no in the destination folder.

I think I'm having the same problem as Mike here: https://github.com/cweagans/docker-bg-sync/issues/8, but I'm definitely using Docker for Mac. I can see:

osxfs                   465.6G    371.4G     80.5G  82% /source
shm                      64.0M         0     64.0M   0% /dev/shm
/dev/sda1                73.1G     10.2G     59.1G  15% /Users/aromero2/dev/iop/Common

/Users/aromero2/dev/iop/Common is the sync destination. Any idea?

cweagans commented 4 years ago

The initial sync takes a ton of time for big file trees. You might try looking at the container logs to see when it's done with the initial sync.

mike-potter commented 4 years ago

@cweagans have you looked at Mutagen? (mutagen.io) . It is very similar to Unison but has direct support for bi-directional syncing into docker containers. And so far it doesn't seem to have the stability issues that Unison had (crashing after syncing very large trees). Also has a good "mutagen monitor" command for seeing exactly what it's doing locally rather than looking at log files. Been using it instead of Unison on other Docker for Mac projects for the past couple of weeks and have been very impressed with its performance and stability.

I wouldn't run Mutagen inside a container like Unison. For me it completely replaced the need for any sort of "docker-bg-sync" tool. Even though I normally hate installing more stuff locally, it's a small "brew install" and works so easily and fast it was worth it for me.

cweagans commented 4 years ago

Thanks! I probably won't use it since it requires installing stuff on the host, but it's definitely good to know about.

alexromero88 commented 4 years ago

Hey @cweagans, thanks for the answer. Definitely it takes time the first time because it's a big tree, but after that it just doesn't detect new changes. Maybe it's related to the problem that @mike-potter mentioned (crashing after syncing large trees). However, it works if I create a cron job and check every minute instead of using repeat=watch

henrymazza commented 3 years ago

I got the info that the sync staste was zero, and the sync could take a while, but the container log didn't give any clue about when it was over. I assumed it was over when docker stats cpu usage dropped and bang! there it worked! I need a way to tell to my users (devs) when they are good to go. Besides that I loved it!

PS: I can't see unison's output like:

         <---- new dir    bar/foo/newdir   
deleted  ---->            bar/user/oldfile1  

[SOLVED]: probably by adding silent=false to SYNC_EXTRA_UNISON_PROFILE_OPTS

henrymazza commented 3 years ago

Hey, could it be changed to make the first sync in a first call to unisson? Then gives a message and start syncing normally? I read somewhere that unisson preservers the sync state across restarts?