Compass watch fails when writes come from a remote SSHFS mount #263
Comments
|
Since Compass was the original inspiration for writing FSSM, and still where I end up using it the most, anything that causes problems for compass users is a big deal in FSSM. Nathan (nex3) actually wrote both the inotify backend for FSSM as well as the library said backend uses. |
|
I've updated the backend in master, and am just trying to figure out how best to reliably reproduce this bug /locally/ so that it can be captured in a test. I'll be setting up another VM to experiment with that, but any suggestions between now and when I get home from work would be greatly appreciated. ^_^ |
|
I'll be taking a new update of fssm before v0.11 ships to fix this and a few other issues. |
|
oh crap. i've been leisurely fixing some things in my task list when i have free time, and the largest contiguous chunk of free time i'll have in... a while is quite possibly right now in the next few hours. how much time do i have? ^_^ ; Particularly, I've been doing a fair chunk of work with rb-fsevent and am almost ready to start integrating improvements in FSSM: https://github.com/thibaudgg/rb-fsevent/commits/master As an aside, C is by far not my favorite language. I keep asking myself if I should just cheat and use objc. Another aside: I want to get rid of the need for the embarrassing workarounds present in both compass and sass by necessity to work around flaws in FSSM. |
|
I'm closing this issue. FSSM is now a proper gem dependency, so you can get fixes as soon as they are released. |
|
I am having this exact same issue using Compass v0.11.1 on my CentOS server via SSH SSHFS mounted using Transmit v4.1.4 (uses MacFUSE). |
|
@featherodd can you please file a bug with fssm? |
|
of course. thank you for the reply :) |
|
resolved in essentially the same fashion: avoid the high latency filesystem operation entirely unless wrapped in a comforting rb-inotify embrace: ttilley/fssm#21 (comment) We've both received multiple complaints about an issue I'm not sure there's a fix for unless using inotify on linux, where the event fires only after the write has completed, or polling, where it only figures it out eventually because it's stuck in an endless loop of asking what changed (...which would be quite possibly the most miserable thing ever when using a high latency network filesystem). Perhaps it's worth having a FAQ entry somewhere re: SSHFS and high latency filesystems when using watch? It's essentially the same as giving up on the bug, but might save someone frustration at some point. Something with an answer of "avoid entirely or enable atomic writes in your IDE/editor"? |
Consider this scenario:
I have a testing server (Debian squeeze) and a workstation (OS X).
All my scss files are on the server and I have Compass watch running on the server.
On the workstation I have a SSHFS mount of the server-side scss-directory for editing.
Inotify events do make up to the server and compass tries to compile the scss files, but the compiled file is empty!
I did lookup for possible causes. Compass uses fssm library and it has the following line:
https://github.com/ttilley/fssm/blob/ac77220b06dae68a070fe042d9e87e78ac2ffd15/lib/fssm/backends/inotify.rb#L8
It apparently listens to the modified event for file changes. I think this causes partly transfered file to be compiled or something similar (since sshfs is kinda slow, because it's running over the network).
This could be fixed by changing the event from modified to close_write. By using close Compass wouldn't process partly transferred files. Also this could happen on local setups if writing takes a long time. Modified event does not necessary mean that the file is in fully saved in editor, but close always means that. I checked with strace that at least vim, emacs, nano and gedit always closes the file on every save. So there is no a real reason to use modify event in Compass.
Disclaimer: I'm no Ruby programmer.
Of course this could not be what fssm is driving for, so this could not be a fssm bug, but a feature.
https://github.com/ttilley/fssm/issues/issue/21
Luckily there are clear workarounds for this problem.
The text was updated successfully, but these errors were encountered: