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

Only syncs once using Docker for Mac #28

Open
alexromero88 opened this issue Jan 9, 2020 · 6 comments
Open

Only syncs once using Docker for Mac #28

alexromero88 opened this issue Jan 9, 2020 · 6 comments

Comments

@alexromero88
Copy link

alexromero88 commented Jan 9, 2020

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: #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?

@alexromero88 alexromero88 changed the title Only sync once using Docker for Mac Only syncs once using Docker for Mac Jan 9, 2020
@cweagans
Copy link
Owner

cweagans commented Jan 9, 2020

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
Copy link

@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
Copy link
Owner

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

@alexromero88
Copy link
Author

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
Copy link

henrymazza commented Mar 30, 2021

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
Copy link

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?

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

4 participants