Closed ms-ati closed 6 years ago
Hm yeah that's a bummer. Using the proxy container seems like a workable solution, my only concern would be whether there will be too much overhead doing a docker exec
for every touch. If that turns out to be the case, we could possibly run sshd
inside the proxy container or come up with some other mechanism for keeping open a long-running connection.
I wouldn't be opposed to option 1, the static binary, either, I'm just not sure about the specifics.
Sorry I haven't been more responsive, I've been traveling without my laptop. If you're going to work toward this I'll hold off on doing anything this week. Thanks!
@codekitchen No worries, I've just proven out an easy solution: literally copy the GNU coreutils touch
binary from a ubuntu:16.04
container into the Dinghy VM. It works perfectly, same version of libc, etc. Will have a PR for you in next few days.
Ok @codekitchen, PRs are up to both homebrew-dinghy
(to pull in the fixes from UNFS3) and fsevents_to_vm
https://github.com/codekitchen/homebrew-dinghy/pull/2 https://github.com/codekitchen/fsevents_to_vm/pull/9
The ball is now in your court to review, and eventually to release a new version of Dinghy to pull in fsevents_to_vm when it is merged! :)
Ping @codekitchen -- hope you get a chance to review this soon! Have a great Memorial Day weekend (assuming you are based in US per your profile)!
Big thanks to @ms-ati for tackling this, it's never fun to wrangle changes in a dependency like unfs3. I've cut a new Dinghy release v4.6.4 with this fix, everything seems to be working well. Please report if you still see the problem or any other issues that may have cropped up.
@codekitchen I recently updated to Catlina (from Sierra) and I am still noticing this issue. I have dinghy 4.6.5 running. I can easily test by changing anything in an xcode project (for example, updating the version number). Because xcode autosaves the change, I see a warning that the file was modified by another process. When I stop dinghy, it works as expected.
@codekitchen ahh, it looks like I may have needed to install unfs from homebrew
@jscheel I had the same problem, do you mind elaborating a bit more how you installed unfs from homebrew?
Hi all, I can't claim to know exactly what is causing it, but our team has identified a major issue impeding development on Dinghy since we upgraded to Mac OS X "High Sierra" recently.
When Dinghy is running, and a file in the shared folder is edited externally (e.g. in Emacs) and saved to disk. When user attempts to edit the file again, something unexpected happens:
It should be noted that the expected thing also happens: the app inside Dinghy observes the change.
We've verified this behavior occurring in all of: Emacs, Sublime Text, and Rubymine, for example. However, for Rubymine, there is a workaround by changing to nio2 file api.
Hypothesis: Is this due to an interaction between the Dinghy NFS server and the new Apple APFS file system, which has nanosecond modification times?
We've verified that
dinghy stop
allows the editors to save files unimpeded by this issue.Any ideas? Anyone else seeing this?