Open ashatrov opened 3 years ago
I am still seeing this behaviour, also when using mutagen-compose.
The crux of the issue here (and in most cases where files appear to mysteriously "sync back") is that the lifetime of the Mutagen synchronization session needs to match the "lifetime" of the locations that it's targeting for synchronization. This is because every sync session maintains an internal virtual "ancestor" representation of the agreed upon file contents that it uses to perform a three-way merge of the contents.
So, for example, if a session is targeting a container or a volume, and that container/volume is recreated (with empty contents), it looks to Mutagen like a deletion of all files on that side, which (absent some safety checks) it would propagate as complete deletion to the other side.
Likewise, if the Mutagen session is deleted/recreated/reset while the sync locations remain intact, then the ancestor is "reset", and both sides appear to have created content (of which Mutagen will propagate any non-conflicting elements). I suspect this is the case that most people are observing with issues like this one.
(Note that pausing or disconnecting a session shouldn't cause problems - the ancestor can be used to reconstruct what happened during that paused/disconnected time. The issue is just when the lifetime of the session/ancestor doesn't match the lifetime of one of the endpoints.)
The idea with Mutagen Compose was to couple the sync session lifetime to the targeted volume lifetime, though I do know of a few issues where the sync session will be recreated (and hence its history reset) independent of the volume lifetime. I'm hoping to fix those next week. For now, the workaround is to perform a full mutagen-compose down --volumes
if the configuration of a synchronization session in the x-mutagen
block changes.
At the moment, I'm also working on a Docker Desktop extension that can be used to synchronized create filesystem caches inside the Docker Desktop VM, which may make things easier for some people and serve as an alternative to Mutagen Compose that doesn't require the Compose wrapper. This is basically a replacement of the Mutagen functionality that was briefly shipped with Docker Desktop, but with significant performance improvements. The critical design aspect for this extension though is that the session lifetime is forcibly coupled to the lifetime of the caches. That should help avoid most of these issues.
I'll ping back on this issue once the relevant changes to Mutagen Compose are made and also once that extension is available.
The idea with Mutagen Compose was to couple the sync session lifetime to the targeted volume lifetime, though I do know of a few issues where the sync session will be recreated (and hence its history reset) independent of the volume lifetime.
Is this the reason why i get a lot of Forcing synchronization cycle for session [...]
when doing mutagen-compose run/up
commands? It seems random - sometimes mutagen doesn't force a synchronization cycle and sometimes it does. However, because of a lof of node_modules and vendor files it always takes 30-40 seconds which is very annoying - esp. when i setup the project and there are like 10 run commands executed.
Any update here? I saw the Docker Desktop extension is already released. I'm using mutagen-compose 0.16.5
Thanks for your help!
Still doing it.
I configured mutagen to sync files of php project from host to docker container on osx. When I switch git branch some files sync back from beta (docker container) to the host. I need 2 ways synchronization because php modify some files (logs, vendors, uploads etc)
Example:
Maybe there is synchronization option or any setting which can solve this issue?
Mutagen version: 0.11.8 Config: