Oliver's picture


I got a little problem and maybe there is someone out there who can help.

Version: Turnkey LAMP Stack with Debian Linux 7

I have my web projects stored on my Windows Computer in htdocs directory. The Windows computer is the host for my Turnkey-VM. The reasons for this configuration are: simple backup, quick edit of files on my main OS Windows, development with my Windows tools eclipse/notepad++.

This dir is shared. I mounted this share in my Turnkey-Linux-VM with the fstab entry

// /media/htdocs cifs credentials=/root/.smbcredentials,uid=1000,gid=100,file_mode=0777,dir_mode=0777 0 0

Not secure, I know. It's simply my Development-VM ;-)

My Apache uses this share by

<VirtualHost *:8000>
DocumentRoot /media/htdocs
<Directory "/media/htdocs">
allow from all
order allow,deny

Everything works fine, except one thing. Using "Compass watch" to compile my scss-files Compass doesn't realize any change of files. So while watching Compass doesn't compile anything.

The setup:

One SSH screen with "compass watch"

Second SSH screen with "nano somewhat.scss" Changing/saving the file makes Compass compile.

Open "somewhat.scss" with e.g. Notepad++ under my Windows, changing/saving the file, Compass is still waiting for changes and does nothing. Restarting Compass in SSH screen One starts the compile process, so I assume my Compass is working properly. It simply doesn't get the change of file.

Hmm, does anyone know why? Any help or documentation appreciated. Thanks for your time in advance.




Jeremy Davis's picture

But my guess is either a Compass setting; or a caching issue. Personally I'd be inclined to contact the Compass community and see if they have any input or ideas.

FWIW TurnKey 13 LAMP appliance is essentially just Debian Wheezy with Apache, MySQL, PHP, Python and Perl - all installed from default Debian repos with no significant customisations. The TKL bits are inclusion of tools such as Webmin, Webshell, etckeeper, TKLBAM, etc). So I'm 99% sure that if you set up your own Debian LAMP you'd have the same experience.

Perhaps a workaround would be to access the files via a different way. I know Notepad++ has a built in SFTP client which I suspect would avoid this issue. Also I have used WinSSHFS to successfully map SSH/SFTP to Win Explorer in the past. It's abandonware and does crash if Windows goes to sleep (when it wakes back up again) but I recall that I worked around that (I don't recall the details but it was essentially configuring Win to kill it when it went to sleep and restart it when it woke up). Installing Samba and connecting to a share on your VM is another option (rather than hosting the share in Windows).

Oliver's picture

First of all, I found out a - let's say - workaroud. Start compass with the parameter --poll

compass watch --poll .

and it'll work. Actually I don't know the mechanism behind by now, but it works :-)

So I'm 99% sure that if you set up your own Debian LAMP you'd have the same experience.

Oh yes, I think so, too.

I don't want to move my project into the VM because I'll loose the chance of quick-edit (without starting the machine). That's why my Windows system should be the server, the VM the client.

Hmm, caching... But why does it work changing any file from a second SSH screen? So, it can't be filesystem caching. And, I tested the time of file while saving from Notepad++ from Windows. The time changed, but compass didn't compile. So, it could be network caching. Is there a chance to bypass samba-client-caching?

And, thanks for your time spending to my problem :-)

Kind regards,

Jeremy Davis's picture

That sounds like a completely reasonable workaround.

And fair enough on your rationale for wanting the FS on your host (and not in the guest).

As for the caching; I imagine that changes in a separate SSH session would propagate instantly as it is affecting the local FS (and therefore the cached copy - which would then replicate to the host once the cache was deemed in need of update).

My thinking goes along the lines of a mounted remote CIFS/SMB share is a remote filesystem; therefore I would assume that files would be locally cached - even if it were only very briefly... Otherwise I would expect that it would constantly be chewing up resources polling the remote FS for changes - although TBH I'm not expert in these things... And your experiments re time of changes (and that propagating straight away) does tend to discredit my theory...

Regardless, I would probably check Samba docs for info (and options) on caching. IIRC TKL v13 has Samba3.6. TBH I don't use Samba any more than I have to but I do use SSHFS a fair bit and IIRC by default it caches for about a minute - although your testing does suggest that Samba may behave differently...

Oliver's picture

for your help. Your thinking seems to be simliar to mine.

I check Samba. If it turns into results, they get posted here.

Thanks again.


Kind regards,

Add new comment