Node.js在 VM 中运行的脚本看不到从主操作系统所做的文件夹更改

Question

我有以下设置：

1. 由Vagrant创建的Ubuntu Lucid 32 VM。
2. 从中开始使用一些CSS和JS文件的文件夹。该文件夹挂载在地址为/vagrant/的 VM 中。
3. grunt.js 监视任务从 VM 启动，监视 css 和 js 文件中的变化。更改文件后，它必须将该文件连接到一个 css 和一个 js 文件。

问题：在咕噜声中监视任务.js没有看到挂载文件夹中的变化。

如果我在 VM 中更改文件，请观察任务正常工作。如果我开始咕噜声.js不是从虚拟盒子，而是从主操作系统，它也可以工作。在Mac OS和Windows 7中尝试过。

仅当从 VM 启动任务并从主操作系统更改文件时，才会出现问题。有解决此问题的方法吗？

更新。有关使用方案的一些详细信息，以便更好地了解上下文：

1. 我们是设计工作室，有 10+ peaple 使用代码。
不同的
2. 人使用不同的操作系统。我们有：Win 7，Mc OS X和Ubuntu Linux。
3. 我们正在从事并支持100 +不同的项目。
4. Prjects使用不同的语言和设置：我们在自己的CMS上有PHP项目，Yii上有PHP项目，Django上有Python项目，还有一些node.js项目。
5. 不同的开发人员可能会在某个时间点处理任何此类项目。
6. 现在，每次我们需要在开发人员的计算机上进行项目工作时，我们都会花费大量时间，而开发人员以前没有使用它。通常我们需要一些已经处理过的开发人员的帮助才能使其工作。

我们想让它更直截了当。为此，我们尝试使用Vagrant和许多预配置的操作系统映像。

现在项目设置如下所示：

1. 来自 git 的开发人员结帐项目。
2. 开发人员在终端中打开项目文件夹。
3. 开发人员进入"流浪者"。
4. 5 分钟后，他已完全配置并完成项目副本。

我们

喜欢这种设置，大多数时候我们没有任何问题。但是在我们的节点.js项目中，我们使用一些css和js预处理器，并且喜欢实时更新它们的文件。并且存在初始帖子的问题。

使用 ssh VM 访问文件和 VM 内项目文件的解决方案可能会起作用，但它们没有解决基本问题（在运行不同操作系统的开发人员组中快速轻松地设置大量项目）

Answer 1

文件/路径观察器依赖于操作系统的较低级别工具，如 Linux 上的 inotify 或 BSD 系统上的 kqueue。这些机制直接与文件系统驱动程序一起使用，它们不会看到网络挂载上的更改。如果您的脚本将在虚拟操作系统上运行，则可以更改共享方向。不要从来宾操作系统内部访问主机操作系统上的共享文件夹，而是使用来宾操作系统上的真实文件夹（实际操作发生的位置）并从主机操作系统访问该文件夹以编辑文件。这样，您的来宾操作系统将像在其生产环境中一样工作，这就是Vagrant所承诺的;但显然未能交付。

我个人使用带有SFTP插件的Sublime Text 2编辑器。在此设置中，我保留了两个文件副本，并在主机操作系统上处理文件。 每当我编辑/添加文件时，我的编辑器都会快速将其上传到服务器，即来宾操作系统。当我移动到生产服务器时，我仍然可以使用相同的方法，这比使用共享文件夹更好。

在切换到Sublime作为我的主要编辑之前，我已经使用Vim十多年了。当时，我没有使用Vim的sftp/ssh设施，这些工具总是有问题，而是使用WinSCP作为SFTP客户端。正确配置后，每当双击服务器上的文件时，它都会在您选择的编辑器上打开它，并且每当保存文件时，WinSCP 都会自动将其上传到服务器。这与我对Sublime的SFTP插件非常接近;但是，文件的本地（主机操作系统）版本是在 WinSCP 动态创建的临时文件夹上创建的。

Sublime的SFTP插件的方法，即在两个系统上都有重复的文件夹，更适合我的需求，因为我也有SpiderOak作为我在主机操作系统上的备份解决方案运行。我喜欢它，因为它保留了文件的版本历史记录。我将其设置为每小时检查一次更改，而不是不断观察以使其执行更流畅，冒着在系统故障时丢失一小时工作的风险。在此设置中，一切都可以完美运行，我确实多次使用其旧版本功能，这使我免于很多苦差事和工作损失。

因此，总而言之，如果您想继续处理共享文件夹，您将做的是在来宾操作系统（您的 Ubuntu）上安装和配置 Samba/NFS/FTP 服务器并共享文件夹。然后，您将从主机操作系统（您的 Mac/Win7）访问网络共享，就像访问任何其他共享远程文件夹一样。如果你的用途和需求与我相似，那么我强烈建议你使用Sublime + SFTP或YourEditor和WinSCP或类似的SFTP客户端。

更新：特别是基于总结为"如果我在 VM 中更改文件，请观察任务正常工作。如果我开始咕噜声.js不是从虚拟盒子，而是从主操作系统，它也可以工作。 在问题中，我对咕噜声.js如何监视文件和文件夹做出了错误的假设。我以为它使用了节点的 fs.* 手表函数;但正如Pyfunc通过一项出色的研究所表明的那样，我的假设是错误的。虽然这不会影响我提出的任何建议的结果，但这是一个错误的技术信息，我必须道歉。因此，看起来问题是由在远程计算机上进行修改时未正确设置文件的修改时间引起的，这可能会使vboxfs对于这种取决于文件修改时间的用途无用。

Answer 2

注意：我没有提出任何完整的解决方案，我也不是JavaScript程序员

关于咕噜声的部分.js关于监视文件的问题

来源： https://github.com/cowboy/grunt/blob/master/tasks/watch.js

它执行文件监视的部分。它使用 fs.statSync（同步统计）：

// Get last modified time of file.
            mtime = +fs.statSync(filepath).mtime;
            // If same as stored mtime, the file hasn't changed.
            if (mtime === mtimes[filepath]) { return; }
            // Otherwise it has, store mtime for later use.
            mtimes[filepath] = mtime;
          }

它使用来自node.js的"fs"功能：http://nodejs.org/api/fs.html#fs_class_fs_stats

在文件的各种数据中，它返回以下时间属性：

atime: Mon, 10 Oct 2011 23:24:11 GMT,
mtime: Mon, 10 Oct 2011 23:24:11 GMT,
ctime: Mon, 10 Oct 2011 23:24:11 GMT 

所以结论是它使用统计数据。您可以从node利用fs编写一个简单的js文件.js以检查更改共享文件夹中的文件前后的fs.statSync结果。

这将确定您是否应该使用grunt.js的观察程序实用程序监视文件。

关于VirtualBox中共享文件夹的小说明

为方便起见，请使用它，就像 vagrant 共享 puppet 配置文件并在 VM 启动后将其应用于 VM 一样。众所周知，随着共享文件夹中文件数量的增加，VirtualBox共享文件夹性能会迅速下降。

对于任何重型提升，请使用其他机制将文件存储在 VM 中的常规目录中。使用 NFS 共享文件夹。

Answer 3

我在Windows 10主机上运行带有VirtualBox的CentOS 7 VM时遇到了同样的问题：browsersync无法检测到VBox共享文件夹中的更改。对我有帮助的是稍微调整了手表流程。浏览器同步使用chokidar来监视文件。设置usePolling: true为我解决了问题。如何使这对您的案例有用？

• 尝试找到一个也使用 chokidar 的咕噜声插件。让观察程序使用轮询。
• 调整观察程序上的设置。