F7每次重建 [英] F7 everytime rebuilds
问题描述
当我的项目和资源位于网络驱动器上时，F7始终会重建。我在谈论Visual Studio 2010，C＃，表单应用程序。网络驱动器由samba共享提供。 smb.conf如下：
When my project and sources are located on a network drive, F7 always rebuilds. I'm talking about Visual Studio 2010, C#, form applications. The network drive is provided by a samba share. smb.conf is as follows:
[global]
protocol = SMB2
[root]
comment =整个文件系统
只读= false
锁定=否
路径= /
主机允许=全部
可写=是
可浏览=是
创建模式= 0644
目录模式= 0755
来宾ok =是
public = yes
[global]
protocol = SMB2
[root]
comment = the whole file system
read only = false
locking = no
path = /
hosts allow = all
writeable = yes
browsable = yes
create mode = 0644
directory mode = 0755
guest ok = yes
public = yes
这是在本地驱动器（C :)上，没有这样的问题。似乎文件的修改时间存在问题。安装Windows的机器是VirtualBox提供的虚拟机，虽然我不认为它是一个原因。有什么想法吗？
我尝试了什么：
我是不知道原因可能是什么。
This is while when on a local drive (C:), there's not such problem. It seems that there's an issue with modification times of files. The machine in which Windows is installed is a virtual machine provided by VirtualBox, although I don't see it as a cause. Any idea?
What I have tried:
I've no clue what the cause may be.
推荐答案
我在过去看到过这种情况，这些共享没有正确同步日期和时间，因此Visual Studio始终认为一些来源已经过时了。
I have seen this in the past where such shares do not sync the dates and times correctly, so Visual Studio always thinks that some sources are out of date.
你可以尝试设置
You can try to set the
dos filetime resolution = yes
fake directory create times = yes选项。这对于较旧的VS版本是必要的，但我不知道最近的VS版本是否仍然按照 smb.conf [ ^ ]：
options. This was necessary with older VS versions but I don't know if recent VS versions still behave as described at smb.conf[^]:
在DOS和Windows FAT文件系统下，最精细的时间分辨率粒度为2秒。为共享设置此参数会导致Samba将报告的时间向下舍入到最接近的两秒边界，此时需要一秒钟分辨率的查询调用是smbd（8）。
当用于Samba共享时，此选项主要用作Visual C ++的兼容性选项。如果在共享上启用了oplock，则Visual C ++使用两个不同的时间读取调用来检查文件自上次读取后是否已更改。其中一个调用使用一秒钟的粒度，另一个使用两秒的粒度。由于两秒钟的调用将向下舍入任何奇数秒，然后如果文件的时间戳为奇数秒，则两个时间戳将不匹配，并且Visual C ++将继续报告文件已更改。设置此选项会使两个时间戳匹配，并且Visual C ++很高兴。
Under the DOS and Windows FAT filesystem, the finest granularity on time resolution is two seconds. Setting this parameter for a share causes Samba to round the reported time down to the nearest two second boundary when a query call that requires one second resolution is made to smbd(8).
This option is mainly used as a compatibility option for Visual C++ when used against Samba shares. If oplocks are enabled on a share, Visual C++ uses two different time reading calls to check if a file has changed since it was last read. One of these calls uses a one-second granularity, the other uses a two second granularity. As the two second call rounds any odd second down, then if the file has a timestamp of an odd number of seconds then the two timestamps will not match and Visual C++ will keep reporting the file has changed. Setting this option causes the two timestamps to match, and Visual C++ is happy.
这篇关于F7每次重建的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
