我们的构build环境将最新版本构build到预定义位置的Windows文件共享上。 当远程用户打开并维护该只读文件共享上的文件夹和文件时，会导致文件locking问题，这会导致我们的构build中断。 有没有什么技术可以为我们解决这个问题？
我想过了
但是迄今为止，这些候选解决scheme似乎都不太适合。
为了澄清，假设“最新版本”的path是\ server \ share \ path \ Latest，并且只有构build服务器具有写访问权限。 有人在“最新”文件夹中的某处打开了一个命令提示符或一个msi文件。 现在构build服务器已经完成，并且需要在复制所有新构build的部分之前清除文件夹中的所有内容。 没有可以做的。
如果一个SMB共享有符号链接的支持或像NTFS这样的交易的某些想法，或者能够重新命名像HFS这样的“开放”目录 – 但是不能。
将所有的二进制文件放在Sharepoint文档文件夹中，正如其他地方所build议的那样，由于数据量的限制，这似乎也是一个糟糕的想法。 我宁愿去一个WebDAV的共享，像一个文件系统挂载，但行为像一个网站。
你的意思是他们实际上是在编辑这些文件，或者这种情况下，没有人真正使用这些文件，但是他们有一个文件锁？
如果他们实际上使用这些文件（或者在编辑器中打开文件，而他们没有甜甜圈），那么您可能不希望这些文件以打开它们的应用程序之外的任何方式打开只读副本，否则将会有潜在的损坏。 你说文件共享是只读的。 那么他们在做什么，不会允许在文件上多次打开只读？ 你没有提到你的构build过程是什么，所以也许这是特定于该工作stream？
您最好的解决scheme可能是尝试从您的开发环境中隔离您的构build环境。 有一个开发过程，检查从回购所有的来源，并build立在一个专用的服务器和专用共享，远离开发人员感动的任何东西。 这样你就不用担心开发者改变了某些东西或者破坏了构build过程，构build过程也不需要担心任何被改变的东西。
如果您使用Linux文件服务器，smb.conf中的这3个选项可能会有用。
strict locking = no blocking locks = no # from man page: Be careful about disabling locking either globally or in a specific service, as lack of locking may result in data corruption. You should never need to set this parameter. locking = no 但是，要使用这些，您将需要一个单独的份额的可写客户端没有上述，我认为这意味着警告不适用。