Problems with git (and composer)

[HnLn]

I have a vagrant box (configured with puphpet) and when running git clone command from within the virtualbox I get errors that certain files can't be deleted. I had a similar issue with jankowfsky winnfsd: https://bitbucket.org/jankowfsky/winnfsd/issue/9/create-acces-ok-write-fail.

I've researched a bit further as I started to realise that it seems the problem only occurs with .git folders (also with composer that uses git). Below is a log from proces monitor as I suspected that maybe the windows host was trying to access the files as well (sourctree or git bash). According the log, that doesn't seem to be the case. Problem seems to be with SetDispositionInformationFile (no idea what that is / does).

The log, the 5th entry is the one causing troubles.

"Time of Day","Process Name","PID","Operation","Path","Result","Detail"
"13:08:21.0964796","winnfsd.exe","7544","CloseFile","D:\www\culturefeed_instance\vendor\symfony\console\Symfony\Component\Console\.git\objects","SUCCESS",""
"13:08:21.0964898","winnfsd.exe","7544","IRP_MJ_CLOSE","D:\www\culturefeed_instance\vendor\symfony\console\Symfony\Component\Console\.git\objects","SUCCESS",""
"13:08:21.0965313","winnfsd.exe","7544","CreateFile","D:\www\culturefeed_instance\vendor\symfony\console\Symfony\Component\Console\.git\objects\pack\tmp_idx_G0HItM","SUCCESS","Desired Access: Read Attributes, Delete, Disposition: Open, Options: Non-Directory File, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened"
"13:08:21.0968146","winnfsd.exe","7544","QueryAttributeTagFile","D:\www\culturefeed_instance\vendor\symfony\console\Symfony\Component\Console\.git\objects\pack\tmp_idx_G0HItM","SUCCESS","Attributes: RANCI, ReparseTag: 0x0"
"13:08:21.0968269","winnfsd.exe","7544","SetDispositionInformationFile","D:\www\culturefeed_instance\vendor\symfony\console\Symfony\Component\Console\.git\objects\pack\tmp_idx_G0HItM","CANNOT DELETE","Delete: True"
"13:08:21.0968839","winnfsd.exe","7544","CloseFile","D:\www\culturefeed_instance\vendor\symfony\console\Symfony\Component\Console\.git\objects\pack\tmp_idx_G0HItM","SUCCESS",""
"13:08:21.0969287","winnfsd.exe","7544","IRP_MJ_CLOSE","D:\www\culturefeed_instance\vendor\symfony\console\Symfony\Component\Console\.git\objects\pack\tmp_idx_G0HItM","SUCCESS",""
"13:08:21.0969780","winnfsd.exe","7544","CreateFile","D:\www\culturefeed_instance\vendor\symfony\console\Symfony\Component\Console\.git\objects","SUCCESS","Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened"
"13:08:21.0970129","winnfsd.exe","7544","QueryDirectory","D:\www\culturefeed_instance\vendor\symfony\console\Symfony\Component\Console\.git\objects\pack","SUCCESS","Filter: pack, 1: pack"

[HnLn]

FYI, did some testing and when using shared folders, the problem doesn't occur.

[jayvdg]

I just encoutered the exact same problem when cloning a git repo:

fatal: fsync error on '/vagrant/qlinix/.git/objects/pack/tmp_idx_A89Huo': Permission denied

Deleting a git folder from the VM gives a comparable error:

rm: cannot remove ‘qlinix/.git/objects/f1/28019df689a43efe1e39ff10781c449649717d’: Input/output error

[jayvdg]

Problem is clearly with winnfsd, reported the bug there too.

[petrepatrasc]

Any updates on the issue? I love the speed of the plugin, but not being able to run composer create-project makes it unappealing.

[johnnyborg]

I think we're having the same issues. The problem starts when we're running composer to install with source. Strangely the problem does not occur when running composer with --prefer-dist. In my situation the problem files are always in the .git folder. Installing the project dependencies ends with the following error:

[RuntimeException]
Could not delete /vagrant/vendor/integrated/library/.git/objects/pack/tmp_idx_zB6mRv:

When looking closer to the file it does not contain write privileges (world, user, group). Like all other files and folders that are synced with NFS which do have these privileges. However the problem also occurs when running (as a cheat) composer as root.

vagrant@vagrant:/vagrant$ ls -al /vagrant/vendor/integrated/library/.git/objects/pack/
total 0
drwxrwxrwx 1 root root 0 Oct 16 07:16 .
drwxrwxrwx 1 root root 0 Oct 16 07:16 ..
-r-xr-xr-x 1 root root 0 Oct 16 07:16 tmp_idx_zB6mRv
-r-xr-xr-x 1 root root 0 Oct 16 07:16 tmp_pack_2WhnzF

We've tried some custom mounting options (like local_lock=none) but is does not seem to affect the issue. Removing the file in the host (Windows) is the only solution to get rid of the file(s).

The output of dmesg gives the following:

[481.995626] NFS: server 172.28.128.1 error: fileid changed
[481.995627] fsid 0:12: expected fileid 0x5d59, got 0x22a

[petrepatrasc]

@Vokx can confirm that we're encountering the same issue on our end. I've switched to the default provider for the composer install operation and reverted afterwards, but we've found the permission issue is also present in two other scenarios:

• committing files (via Git) in a shared folder.
• attempting to create symbolic links in a shared folder.

[johnnyborg]

@petrepatrasc Do you have a case when it used to work? We'd like to use NFS due to the fact that it syncs both ways. I can not confirm it (yet) but i do believe it used to work, when passing the option nfs:true (in the Vagrantfile). I will check tomorrow when i have some time to downgrade Vagrant. I think that symbolic links are not supported on NFS mounts. Also passing options to mount_options should override the default set (i believe) of options and this does not happen either (but i do need to check that).

[Oliboy50]

👍 same issue while running composer update

[RuntimeException]
Could not delete /.../.git/objects/pack/tmp_pack_yceleg

Hope this will be fixed soon cause I love this plugin but I'll have to use vboxsf instead by now.

[luciansabo]

any update on this?

[Hyunk3l]

same error here....

[lvancrayelynghe]

+1 :(

[lvancrayelynghe]

You should try the fork from Yann Schepens : https://bitbucket.org/yannschepens/winnfsd/downloads

He made a lot of pull requests here, https://bitbucket.org/jankowfsky/winnfsd/pull-requests .

Replace your "winnfsd.exe" with the one from Yann Schepens (it's located in "C:\Users[YourUserName].vagrant.d\gems\gems\vagrant-winnfsd-1.0.10\bin")

I'm actually giving it a try, looks like it solves this particular problem

[GM-Alex]

Yann is close to a solution for this issue. So give use some more time.

[lvancrayelynghe]

👍

[gyzo]

👍

[BenMorel]

👍

[lukey78]

any news?

[willmorgan]

@lukey78 FWIW, if, like me, you are using NFS for reasons of speed on Windows hosts only, then I would suggest to use rsync sharing in the meantime by using Cygwin rsync, adding the Cygwin bin dir to your Windows path, and then doing a vagrant reload.

[lukey78]

@willmorgan: Yeah, I considered that, but I like to use NFS because of the two-way data synchronization. Just syncing from dev machine to vagrant box is also possible with our dev IDE (PhpStorm).

[willmorgan]

@lukey78 vagrant rsync-auto is your friend 😄

Also you could just get screen from cygwin and do: screen -d -m vagrant rsync-auto

[lukey78]

@willmorgan: rsync-auto just seems to watch for file changes on host side. Files created or changed in the vagrant box are never synchronized back to the host.

[willmorgan]

@lukey78 Ah, apologies - of course, you are correct.

There are other Vagrant plugins that handle rsync "pulls" apparently. But looks like it's vboxsf for me for now :(

[krisdante]

@benoth good hint with https://bitbucket.org/yannschepens/winnfsd/downloads. My problem is gone

[michael-franz]

It seems the problem is gone with version 1.0.11.

[worthwhileindustries]

what version/repo of WinNFSd is currently being used in the project?

[GM-Alex]

Yann is part of the winnfsd project (https://bitbucket.org/jankowfsky/winnfsd), which also part of this project. All of his changes are merged with the latest version and also included in the latest version of the module.

[eXtreme]

With 1.0.11 many problems have been solved by i'm suffering from some new as well - can live with them but they are annoying. Anyway, it's great to see this project!

1. with composer update/install I get an error that my composer.lock or vendor/composer/installed.json is corrupted (just after packages are updated) - at the end of these files there are some leftovers from previous version of the file? Json is corrupted with some old lines. I manually remove them and run the command again and it works.
2. sometimes files are not updated on guest after modifying on host. I have to wait longer or make more more changes or even change other files to "trigger" updating.
3. sometimes new files in a folder are not transferred to guest. Reproducible situation on my machine: create a folder, create some files there, modify them, then create new files in that folder - new files are never transferred to guest. I have to vagrant reload to make them appear.

If there is a way I can provide you some logs or anything - tell me how, I will reproduce these problems and create new issue. right, there is config.winnfsd.logging, I will try that tomorrow :)

[GM-Alex]

All these issue are related to the winnfsd project (https://bitbucket.org/jankowfsky/winnfsd), so it would be better to continue the discussion there. I will close the issue here.

[lukebennett]

Just for the record, I'm unable to git pull/commit/stash etc (basically anything that manipulates the .git directory) in 1.0.11, including with Yann's forked executable. Unfortunately it would appear that any fix has stalled as there's been no activity on the winnfsd issue for a couple of months.

[GM-Alex]

Yes, Yann and I are full with work to do, so there is no time at the moment for that. Maybe someone with some C++ experience want to join. We are using git directly on windows at my company what works without any problems, that's no solution but a good workaround for the daily work.

[lukebennett]

Sure, would help if I could but sadly I don't do C++. We're able to use Git on Windows fine, we just need the ability to do so within the Vagrant guest as well. We'll sit tight and wait on this I guess as none of the other Vagrant synced folder implementations are really suitable.

[GM-Alex]

You could test http://www.hanewin.de/nfs-d.htm maybe that one will work with git. If it's like that it could be a option to extend the vagrant module to check if some installed the alternative server (which will be easier than fixing the issue), but this one is shareware.

[lukebennett]

Actually, it looks like I may have goofed up here - despite installing the 1.0.11 plugin, it turns out Vagrant was still using 1.0.10 for some reason. Having forcefully removed that and made sure 1.0.11 is in use, I'm not getting the issue any more.

[worthwhileindustries]

@lukebennett how did you find that out? I noticed that vagrant keeps old plugins and often wonder if it is using an old one? Did you just do a vagrant plugin list and it showed the old version?

[lukebennett]

@worthwhileindustries Pure luck really - at no point did I explicitly upgrade any of my plugins. I started noticing some adverse behaviour with a different plugin and after investigating realised Vagrant had automatically installed new versions for both that and winnfsd.

As the other plugin was definitely running on the new version, I assumed winnfsd was too, Vagrant seemingly having updated both without prompting. What made me realise winnfsd was still on the old version was when I happened to spot the old exe running in Task Manager.

If anybody knows how Vagrant decides when to install and/or switch plugins, feel free to enlighten me :)

[lecajer]

Hi, I'm using Vagrant 1.7.2 and vagrant-winfsd 1.0.11 on a Windows 8.1 and I'm still getting weird issues like "Input/output error"

Example on composer install :

 Could not delete /dev/project/vendor/name/lib/.git/objects/pack/tmp_idx_SeJiQh:

[krisdante]

Same for me. I'll try to use Vagrant started as Administrator today, and it that also fail I'll just give up with NFS.

[lecajer]

I found a workaround concerning vendor installation. Use dist package so there wont be a .git folder where files can't be deleted

php composer.phar install --prefer-dist

[razbakov]

I am using 1.0.11, i tried workaround jankowfsky/winnfsd and php composer.phar install --prefer-dist.
Nothing works for me

[lukasvice]

👍

[mreichenbach-igniti]

I have the same problem like @jeremlicious with the same versions of Vagrant and vagrant-winnfsd, but only using Windows 7. I also checked the version of winnfsd.exe which is the current v2.0

[luciansabo]

I personally switched to Linux because of this issue

[worthwhileindustries]

I am using global install of composer installed on a non-shared directory within the vm. I run composer within the vm in the shared directory... not on windows. Maybe this is the problem? I've never ever had a single issue using composer to update my shared libraries in my git repo in the shared directory and I've been using this plugin for 6+ months everyday. I'm currently running Windows 8.1. VirtualBox 4.3.22

[6be709c0]

👍

[MetalArend]

Where exactly on the winnfsd issues tracker do they follow up on this issue? @GM-Alex, could you please reference some specific issue, if there is one? I keep running into this, and would love to help to get some insights if it would help to solve the problem.

[eXtreme]

@MetalArend https://bitbucket.org/jankowfsky/winnfsd/issues/7/winnfsd-doesnt-always-overwrite-files this issue provides latest compiled .exes with newest fixes.

[ghost]

@eXtreme you can read it here; https://bitbucket.org/jankowfsky/winnfsd/issues/9/create-acces-ok-write-fail. You can replace the current binaries provided by Yann Schepens to resolve this ticket. I don't when @GM-Alex will provide a new version of the Vagrant plugin.

[yannschepens]

@johnnyborg: Thk
Le ven. 10 juil. 2015 à 10:54, johnnyborg notifications@github.com a
écrit :

@eXtreme https://github.com/eXtreme you can read it here;
https://bitbucket.org/jankowfsky/winnfsd/issues/9/create-acces-ok-write-fail.
You can replace the current binaries provided by Yann Schepens to resolve
this ticket. I don't when @GM-Alex https://github.com/GM-Alex will
provide a new version of the Vagrant plugin.

—
Reply to this email directly or view it on GitHub
#22 (comment)
.