Cygwin SVN：E200030：SQLite磁盘I / O错误 [英] Cygwin SVN: E200030: SQLite disk I/O error
问题描述
当我在Cygwin中使用Subversion更新一些存储库时，一些目录更新成功，而其他一些获得失败并显示错误消息：
svn：E200030：sqlite：disk I / O错误
执行 svn update 再次为同一个存储库，不同的目录可以得到相同的错误。有时，在上述错误消息之后有一条SVN指令。 /cygwin.com/ml/cygwin/2012-04/msg00079.htmlrel =nofollow noreferrer>有人想要的改变在Cygwin的 SQLite 包。
更改以Cygwin SQLite版本的形式发布 3.7.12.1-1 ，它修复了一个人的问题，但它有这个不良的副作用，阻止Cygwin的Subversion包与本机Windows Subversion实现协作。
发生了什么？
这里的核心问题是 Subversion 1.7更改了磁盘格式的工作副本。部分更改涉及一个新的SQLite数据库文件 .svn / wc.db 。现在，为了实施 SQLite的并发保证，SQLite在访问数据库文件时锁定它。
这很好，很明智，但是当你尝试混合使用Windows本机和POSIX 文件锁定语义。在Windows上，文件锁几乎总是意味着强制锁定，但在Linux系统上， Cygwin试图模仿—锁定通常意味着忠告锁定。
这有助于了解磁盘I / O错误的来源。
Cygwin SQLite 3.7.12.1-1 更改是以Unix模式而不是Cygwin模式构建库。在Cygwin模式下，库使用Windows本地文件锁定，这违背了Cygwin的理念：在可能的情况下，Cygwin包调用POSIX函数而不是直接指向Windows API，因此 cygwin1.dll 可以提供正确的POSIX语义。
POSIX通知文件锁定正是你想要的SQLite，当所有的程序访问SQLite DBs有问题是建立Cygwin，这是Cygwin中的默认假设。但是，当您运行Windows原生的Subversion程序（如TortoiseSVN）和纯POSIX Cygwin svn 时，会产生冲突。当TortoiseSVN Windows资源管理器外壳扩展有 .svn / wc.db 文件锁定的强制锁和Cygwin svn 来试试一个咨询锁，它立即失败。 Cygwin svn 假设锁尝试将立即成功或阻塞，直到它可以成功，因此将锁失败解释为磁盘I / O错误。
我们如何解决这个困境？
在Cygwin中，我们总是试图在Windows本地程序尽可能好地玩。诀窍是找到一种方法，同时仍然与Cygwin程序玩得很好。
不是每个人都同意我们应该尝试这个。 Cygwin SQLite是Cygwin的一部分，所以它只需要与其他Cygwin程序一起工作，一个团队说。对等方会回答，Cygwin在Windows上运行，所以它必须在其他Windows程序中运行良好。
幸运的是，我们想出了一种方法， http://cygwin.com/ml/cygwin-announce/2013-06/msg00006.html =nofollow noreferrer>新功能 Corinna Vinschen 添加到 cygwin1.dll 版本1.7.19。它允许程序通过BSD文件锁定API请求强制性文件锁定。我的部分改变是使Cygwin SQLite在用户的方向打开和关闭此功能，允许相同的软件包满足Cygwin中心和Windows本地阵营的需要。
这个Cygwin DLL特性在1.7.20中得到了进一步的改进，我使用完成的锁定语义发布了Cygwin SQLite 3.7.13-3 。此版本允许选择三种锁定策略：POSIX建议锁定，BSD建议锁定和BSD / Cygwin强制锁定。到目前为止，后一种策略已经证明与原生Windows锁定完全兼容。
后来，当Jan Nijtmans接管了Cygwin SQLite的维护，他进一步增强了这种机制将其与 SQLite VFS层完全集成。这允许第四个选项：Cygwin SQLite在我们开始之前使用的本机Windows锁定。这主要是针对BSD / Windows锁定策略不能与本机Windows SQLite程序完全合作的可能性。就我所知，没有人需要使用这个选项，但很高兴知道它在那里。
替代补救
如果你所遇到的冲突是Cygwin的命令行 svn 和TortoiseSVN Windows资源管理器外壳扩展之间，还有另一个选项来修复它。 TortoiseSVN也附带本机Windows Subversion命令行程序。如果你把这些放在你的 PATH 之前的Cygwin的 bin 目录，你不应该遇到这个问题。
When I use Subversion in Cygwin to update some repository, some directories update with success, while some other one gets a failure with the error message:
svn: E200030: sqlite: disk I/O error
When doing svn update again for the same repository, a different directory can get the same error. Sometimes, there is a SVN instruction after the above error message.
This happened due to a change someone wanted in Cygwin's SQLite package. I was the maintainer of that package when this question was asked, and I made the change that caused this symptom.
The change was released as Cygwin SQLite version 3.7.12.1-1, and it fixed that one person's problem, but it had this bad side effect of preventing Cygwin's Subversion package from cooperating with native Windows Subversion implementations.
What Happened?
The core issue here is that Subversion 1.7 changed the working copy on-disk format. Part of that change involves a new SQLite database file, .svn/wc.db. Now, in order to implement SQLite's concurrency guarantees, SQLite locks the database file while it is accessing it.
That's all fine and sensible, but you run into a problem when you try to mix Windows native and POSIX file locking semantics. On Windows, file locking almost always means mandatory locking, but on Linux systems — which Cygwin is trying to emulate — locking usually means advisory locking instead.
That helps understand where the "disk I/O error" comes from.
The Cygwin SQLite 3.7.12.1-1 change was to build the library in "Unix mode" instead of "Cygwin mode." In Cygwin mode, the library uses Windows native file locking, which goes against the philosophy of Cygwin: where possible, Cygwin packages call POSIX functions instead of direct to the Windows API, so that cygwin1.dll can provide the proper POSIX semantics.
POSIX advisory file locking is exactly what you want with SQLite when all the programs accessing the SQLite DBs in question are built with Cygwin, which is the default assumption within Cygwin. But, when you run a Windows native Subversion program like TortoiseSVN alongside a pure POSIX Cygwin svn, you get a conflict. When the TortoiseSVN Windows Explorer shell extension has the .svn/wc.db file locked with a mandatory lock and Cygwin svn comes along and tries an advisory lock on it, it fails immediately. Cygwin svn assumes a lock attempt will either succeed immediately or block until it can succeed, so it incorrectly interprets the lock failure as a disk I/O error.
How Did We Solve This Dilemma?
Within Cygwin, we always try to play nice with Windows native programs where possible. The trick was to find a way to do that, while still playing nice with Cygwin programs, too.
Not everyone agreed that we should attempt this. "Cygwin SQLite is part of Cygwin, so it only needs to work well with other Cygwin programs," one group would say. The counterpartisans would reply, "Cygwin runs on Windows, so it has to perform well with other Windows programs."
Fortunately, we came up with a way to make both groups happy.
As part of the Cygwin SQLite 3.7.17-x packaging effort, I tested a new feature that Corinna Vinschen added to cygwin1.dll version 1.7.19. It allowed a program to request mandatory file locking through the BSD file locking APIs. My part of the change was to make Cygwin SQLite turn this feature on and off at the user's direction, allowing the same package to meet the needs of both the Cygwin-centric and Windows-native camps.
This Cygwin DLL feature was further improved in 1.7.20, and I released Cygwin SQLite 3.7.13-3 using the finalized locking semantics. This version allowed a choice of three locking strategies: POSIX advisory locking, BSD advisory locking, and BSD/Cygwin mandatory locking. So far, the latter strategy has proven to be completely compatible with native Windows locking.
Later, when Jan Nijtmans took over maintenance of Cygwin SQLite, he further enhanced this mechanism by fully integrating it with the SQLite VFS layer. This allowed a fourth option: the native Windows locking that Cygwin SQLite used to use before we started on this journey. This is mostly a hedge against the possibility that the BSD/Windows locking strategy doesn't cooperate cleanly with a native Windows SQLite program. So far as I know, no one has ever needed to use this option, but it's nice to know it's there.
Alternate Remedy
If the conflict you're having is between Cygwin's command line svn and the TortoiseSVN Windows Explorer shell extension, there's another option to fix it. TortoiseSVN ships with native Windows Subversion command-line programs as well. If you put these in your PATH ahead of Cygwin's bin directory, you shouldn't run into this problem at all.
这篇关于Cygwin SVN：E200030：SQLite磁盘I / O错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
