Когда я использую Subversion в Cygwin для обновления некоторого репозитория, некоторые каталоги обновляются с успехом, а некоторые другие получают сообщение об ошибке с сообщением об ошибке:
svn: E200030: sqlite: ошибка ввода-вывода диска
При повторении svn update для одного и того же репозитория другой каталог может получить ту же ошибку. Иногда после сообщения об ошибке появляется команда SVN.
Это произошло из-за изменение, которое кто-то захотел в Cygwin SQLite. Я был сторонником этого пакета, когда этот вопрос был задан, и я сделал изменение, вызвавшее этот симптом.
Это изменение было выпущено как версия Cygwin SQLite 3.7.12.1-1, и он исправил проблему с одним человеком, но имел этот плохой побочный эффект, препятствующий взаимодействию Cygwin Subversion с собственными реализациями Subversion для Windows.
Основная проблема здесь в том, что Subversion 1.7 изменил рабочую копию на диске. Часть этого изменения включает новый файл базы данных SQLite, .svn/wc.db. Теперь, чтобы реализовать SQLite concurrency гарантирует, SQLite блокирует файл базы данных во время доступа к ней.
Это все прекрасно и понятно, но вы столкнулись с проблемой, когда пытаетесь смешивать Windows native и POSIX семантику блокировки файлов. В Windows блокировка файлов почти всегда означает обязательную блокировку, но в системах Linux -— который Cygwin пытается подражать; блокировка обычно означает консультативное блокирование вместо этого.
Это помогает понять, откуда происходит "ошибка ввода-вывода диска".
Изменение Cygwin SQLite 3.7.12.1-1 заключалось в том, чтобы создать библиотеку в режиме "Unix" вместо "Cygwin mode". В режиме Cygwin библиотека использует встроенную блокировку файлов Windows, что противоречит философии Cygwin: по возможности пакеты Cygwin вызывают функции POSIX вместо прямого доступа к API Windows, так что cygwin1.dll может предоставить правильную семантику POSIX.
Консолидация файлов POSIX - это именно то, что вы хотите с SQLite, когда все программы, обращающиеся к SQL-серверам SQLite, строятся с помощью Cygwin, который является предположением по умолчанию в Cygwin. Но когда вы запускаете собственную программу Subversion для Windows, такую как TortoiseSVN, вместе с чистым POSIX Cygwin svn, вы получаете конфликт. Когда расширение оболочки TortoiseSVN для Windows Explorer имеет файл .svn/wc.db, заблокированный с обязательной блокировкой, и Cygwin svn приходит и пытается получить консультативную блокировку на нем, он немедленно сработает. Cygwin svn предполагает, что попытка блокировки будет либо успешной, либо заблокирована до тех пор, пока она не удастся, поэтому она неправильно интерпретирует ошибку блокировки как ошибку ввода-вывода диска.
В Cygwin мы всегда стараемся играть с родными программами Windows, где это возможно. Хитрость заключалась в том, чтобы найти способ сделать это, в то же время хорошо играя с программами Cygwin.
Не все согласились, что мы должны это сделать. "Cygwin SQLite является частью Cygwin, поэтому ему нужно только хорошо работать с другими программами Cygwin", - сказала одна группа. Контрпартнеры ответят: "Cygwin работает в Windows, поэтому он должен хорошо работать с другими программами Windows".
К счастью, мы придумали способ сделать обе группы счастливыми.
В рамках усилий по сбору упаковки Cygwin SQLite 3.7.17-x я протестировал новую функцию, которая Corinna Vinschen добавлена в cygwin1.dll версия 1.7.19. Это позволило программе запрашивать обязательную блокировку файлов через API-блокировки файлов BSD. Моя часть изменения заключалась в том, чтобы заставить Cygwin SQLite включить и отключить эту функцию в пользовательском направлении, позволяя тому же самому пакету удовлетворять потребности как в лагерях, ориентированных на Cygwin, так и в Windows.
Эта функция DLL Cygwin была дополнительно улучшена в 1.7.20, и я выпустил Cygwin SQLite 3.7.13-3 с использованием финализированной семантики блокировки. Эта версия позволила выбрать три стратегии блокировки: консультативную блокировку POSIX, предварительную блокировку BSD и обязательную блокировку BSD/Cygwin. До сих пор последняя стратегия оказалась полностью совместимой с встроенной блокировкой Windows.
Позже, когда Ян Нийтманс взял на себя обслуживание Cygwin SQLite, он еще больше укрепил этот механизм, полностью интегрировав его с SQLite VFS layer. Это позволило сделать четвертый вариант: встроенная блокировка Windows, которую Cygwin SQLite использовал перед тем, как мы начали в этом путешествии. Это в основном хеджирование против возможности того, что стратегия блокировки BSD/Windows не взаимодействует с использованием собственной программы Windows SQLite. Насколько мне известно, никто никогда не должен был использовать этот вариант, но приятно знать его там.
Если конфликт, который у вас есть, находится между командной строкой Cygwin svn и расширением оболочки Windows Explorer TortoiseSVN, есть еще одна возможность его исправить. TortoiseSVN также поставляется с родными программами командной строки Windows Subversion. Если вы поместите их в свой PATH перед каталогом Cygwin bin, вы не должны запускать эту проблему вообще.
Попадая на ту же проблему, она появляется (по крайней мере, в моем случае) как взаимодействие с TortoiseSVN. Отключение кэша значков состояния TortoiseSVN ( "Настройки" > "Наложения значков" > "Ключ состояния" "Нет" > "Применить" ) имеет все, что работает для меня отлично.
(Очевидно, что это не устраняет основную проблему, которая, как представляется, связана с пакетом SQL, который пакет Cygwin Subversion полагается на изменение своего режима доступа. Когда я пишу, там активно [если медленное] обсуждение в рассылке Cygwin список о том, как решить эту проблему.)
ldd /usr/bin/svn показывает, что SVN зависит от /usr/bin/cygsqlite 3-0.dll.
После того как я изменил libsqlite3 с 3.7.12 до 3.7.3, проблема, похоже, исчезла. Таким образом, это может быть проблема SQLite.
Используя TortoiseSVN, отключение Refresh shell overlays в clean up решило проблему для меня.
Для других ссылок у меня была такая же ошибка (svn: E200030: sqlite: disk I/O error) и я обнаружил, что один из моих файлов журнала занимал все мое пространство (и не мог записать на жесткий диск, потому что свободного места не было).
Запуск (чтобы убедиться, что у вас достаточно свободного места на диске)
df -h
(Если вы не удаляете некоторые большие файлы (я просто удалил некоторые файлы резервного копирования и журнала)
Тогда мне просто нужно было запустить:
svn cleanup
Это разрешило ошибку для меня.