search

winnfsd / vagrant-winnfsd

Manage and adds support for NFS for Vagrant on Windows.
Other
570 stars 61 forks source link

Some (large) files randomly become blank during running of build tool in guest #101

Open brockfanning opened 8 years ago

brockfanning commented 8 years ago

I have been running into an issue whenever I run a build tool inside the guest. (The tool in my case is "drush make" for a Drupal site, which downloads a lot of packages at once and saves them to the filesystem.) Each time, one or more random files become blank. The only pattern I have been able to find is that they are usually larger files (such as very long javascript or PHP files).

I don't have this problem with other synced folder types, like rsync. I don't know whether this is the kind of thing that can be fixed in a plugin, but figured I would start here, to see if anyone has run into the same thing or figured out a fix. My current workaround is to use NFS most of the time, but switch to something else whenever I need to run this build tool. That's a bit painful though, so it would be great to figure out something more long-term.

In case it's relevant, I'm on Windows 7. I have tried a wide variety of mount_options variations, but nothing fixes the problem for me.

Any ideas welcome! Thank you.

marcharding commented 8 years ago

Can you paste your mount options and guest os? You can also try using TCP instead of UDP.

brockfanning commented 8 years ago

Hi marcharding, thank you for the reply. I'm getting this behavior even with no mount options. Today I tried a mount_options of ['tcp'], but afterwards I was not able to do a "git status" inside the guest - or at least, it was taking prohibitively long, so I had to abort.

The guest OS is Ubuntu 14.04.

Sorry I don't have more details. Do you think it would help if I were able to output some more debugging info?

marcharding commented 8 years ago

Are you using the latest version of the plugin (1.3.0)? Please check with vagrant plugin list.

brockfanning commented 8 years ago

Hi, yes I'm using 1.3.0.

marcharding commented 8 years ago

Ok, can you share the drush-make file?

Maybe i can reproduce the error which may help me fix it.

brockfanning commented 8 years ago

I was trying to distill the drush make file down to the minimum amount to recreate the problem, and got it down to just 2 items. Then I tried experimenting with the same drush make file in a fresh git repository, and I didn't see the problem. So I revamped my synced folder setup so that, instead of just syncing the root folder of the project (which includes .git) I am now syncing 4 subdirectories of the root folder. After doing this, I went back into the guest and ran drush make, and no longer had the blank file problem.

So it seems like this was related to the .git folder (which in our case is probably very large). My solution means that I can no longer do git operations inside the guest, but I think I'm OK with that, since they go much faster in the host.

I think I'm good with this workaround, so feel free to close this unless you want to pursue it. I'm slowly zeroing in on a best-practice for Windows/Vagrant development, and at the moment it is looking like NFS, via this plugin (thanks!), but without syncing the .git folder, and doing Git operations in the host, and everything else in the guest.

marcharding commented 8 years ago

I'd really like to fix this but without a reproduceable testcase there is not much i can do.

brockfanning commented 8 years ago

The best way I can describe a test case is:

  1. Start with a really big repository (large project with a decent history)
  2. Set up a Vagrant box with and nfs sync on the project root folder, which includes the .git folder
  3. Inside the VM (assuming drush is installed), run the supplied drush make file with: drush make --no-core path/to/drush-make-file
  4. Create a temp branch and commit the results of the drush make
  5. Run the drush make command again
  6. Do a "git diff" to see which files became blank

Here is an example of a drush make file that was producing the problem for me:

core = 7.x
api = 2

libraries[colorbox][type] = libraries
libraries[colorbox][download][type] = file
libraries[colorbox][download][url] = https://github.com/jackmoore/colorbox/archive/1.5.9.tar.gz
libraries[colorbox][directory_name] = colorbox
libraries[colorbox][do_recursion] = FALSE

libraries[historyjs][type] = libraries
libraries[historyjs][download][type] = git
libraries[historyjs][download][url] = https://github.com/browserstate/history.js.git
libraries[historyjs][download][revision] = 14968aa3cf2a27335f71d26386de0a5c4073835d
libraries[historyjs][directory_name] = "history.js"
doctor-beat commented 6 years ago

Same here when unzipping a war file into a nfs mounted target folder. V1.4.0. Windows 10 host. Some jar files (always the same if feels) are left blanl/empty

ghost commented 3 years ago

Very glad I found this issue as I experience it once a month or so when using WP-CLI. When using the wp core update command (which updates WordPress) I occasionally experience files becoming corrupt (half empty/incomplete) which wreaks havoc as I have to download/restore those files manually.

Windows 10 Pro Vagrant 2.2.14 vagrant-winnfsd (1.4.0, global)

I'm sorry I'm not providing more detail or replication instructions, just thought I'd post to increase the issue visibility. Thanks!