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

Geddy problem in Vagrant #561

Open
mewben opened this Issue Mar 4, 2014 · 4 comments

Comments

Projects
None yet
3 participants

mewben commented Mar 4, 2014

I have Ubuntu 12.04 x64 LTS setup on my vagrant. I managed to successfully install nodejs and geddy.

I installed my geddy app - sample in /vagrant/sample. When I first run geddy, it was successful. But on the second time (even when I restart the vm), It throws an error:

cp -r /vagrant/sample/log/stdout.log /vagrant/sample/log/stdout.2014-03-04T03:47:02.log

fs.js:427
   return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);
                  ^
Error: UNKNOWN, unknown error '/vagrant/sample/log/stdout.2014-03-04T03:47:02.log'
    at Object.fs.openSync (fs.js:427:18)
    at Object.fs.writeFileSync (fs.js:966:15)
... (too long)

But when I delete the logs folder, geddy starts successfully again.
Now, everytime I restart geddy, I have to delete the logs folder. :(

I tried creating a new app on my /home folder. There seems to be no problem with geddy installed on it. So I guess this is due to the shared folder /vagrant.

Does geddy have something like --no-bin-links option like in npm install gulp --no-bin-links? Because I noticed that I can't install packages like gulp without the --no-bin-links flag inside the /vagrant folder.

I hope somebody can address to my concern. Thank you.

Contributor

mde commented Mar 4, 2014

It looks like it's failing when trying to back up the previous log file. I seem to remember someone else having a similar file-paths problem when running Vagrant. Are you running it on Windows?

mewben commented Mar 5, 2014

Yes I'm running Windows 8 host. And Ubuntu 12.04 on my VM...

er1z commented Mar 6, 2014

Why you cannot? And what image are you using?

Contributor

mde commented Mar 7, 2014

I seem to remember somebody else having this problem. It might have something to do with the underlying filesystem being Windows. It's either that, or the fact that it's a VM has it returning bogus paths for the log files.

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