Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Compass watch fails when writes come from a remote SSHFS mount #263

epeli opened this Issue Jan 26, 2011 · 9 comments


None yet
4 participants

epeli commented Jan 26, 2011

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:

  @notifier.watch(handler.path.to_s, :recursive, :attrib, :modify, :create,
                  :delete, :delete_self, :moved_from, :moved_to, :move_self)


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.


Luckily there are clear workarounds for this problem.


ttilley commented Jan 26, 2011

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.


ttilley commented Jan 26, 2011

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. ^_^


chriseppstein commented Mar 17, 2011

I'll be taking a new update of fssm before v0.11 ships to fix this and a few other issues.


ttilley commented Mar 17, 2011

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.


chriseppstein commented Apr 25, 2011

I'm closing this issue. FSSM is now a proper gem dependency, so you can get fixes as soon as they are released.

01iv3r commented May 18, 2011

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).
scss file saved from Textmate 1.5.10 to SSHFS mount.
compass sees the file changes but compiles a bunch of blank css files 80% of the time,
the other 1 in 5 times it will properly generate only some of the css files.


chriseppstein commented May 18, 2011

@featherodd can you please file a bug with fssm?

01iv3r commented May 18, 2011

of course. thank you for the reply :)


ttilley commented May 18, 2011

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"?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment