好的，完成Visual Studio＆amp; Windows开发noob在这里 - 这是一个简单的答案。
我刚开始致力于将Linux C ++库移植到Windows。现有的源代码树位于Linux文件系统上，VS运行在安装了Linux文件系统的Windows 7 VM中。
我将源代码树添加到一个新项目中 - 我最初是在linux端进行编辑，但现在我已经从VS IDE中完成了一些操作。但那些编辑并没有出现在磁盘上？我已经完成了典型的保存：ctrl-s，完成＆＃34;保存所有＆＃34;：ctrl-shift-s，从菜单中保存等等。如果我查看磁盘上的文件linux方面，这些变化都没有。
我已经关闭了＆amp;重新启动VS，它仍然会在重启时看到更改。如何将更改恢复到实际磁盘上，以便我可以提交subversion等？
我已确认文件＆amp;文件系统可从Windows VM读取/写入。
我确定这对某人有意义，但如果我得到它，我会被诅咒。
Windows 7上的Visual Studio Professional 2013
答案 0 :(得分：0)
你不应该在两种环境下阅读/写入同一目录，imo。其中最重要的原因是* nix＆amp; windows对行结尾有不同的想法。
在主机操作系统（或像github这样的服务器上）保留一个git存储库并从Windows VM中拉/推到该存储库会好得多。 Git非常聪明，能够自动处理所有行结尾，符号链接，权限等。
答案 1 :(得分：0)
我见过使用BC ++ IDE的类似行为。 在我的情况下，我试图编辑与第二个目录（在同一个NTFS文件系统上）中的文件的硬链接的文件。 IDE正在使用某种机制将要编辑的文件重新定位到_history备份目录中。
即。编辑器取消链接原始目录中的原始文件，并将其重新链接到_history子目录中，并为编辑后的文件创建一个全新的目录条目。 我在第二个目录中创建的硬链接文件然后链接到_history目录中的备份文件，因此当我使用记事本编辑第二个目录中的文件时，修改将显示在_history备份文件中（或反之亦然）但不会原始位置的文件。
它不像简单的文本编辑器（记事本），其中编辑的文件被打开 - 读取 - 关闭并且在保存时，使用相同的目录条目重新打开 - 关闭。 我假设IDE使用低级Windows文件系统函数将原始文件重命名/链接到_history 目录并且此机制不支持/识别NTFS硬链接。我怀疑在你的情况下，VS可能使用类似的重新链接机制（特定于NTFS），类似地不能与挂载的Linux文件系统中的文件一起使用。 VS可能正在将编辑存储在临时文件中（可能是隐藏的或在某些其他临时目录中），因此如果IDE崩溃，原始文件不会丢失。提交文件保存时，它会尝试将原始文件链接到备份，然后尝试将临时编辑文件重新链接到原始目录条目位置，但由于NTFS文件系统链接机制与Linux文件系统不兼容，因此没有任何反应。 [我确实观察到编辑MicroSoft Office文档时临时文件如下所示。 notepad ++也这样做，所以我怀疑VS做的是同样的事情。]