Cygwin SVN: E200030: error de E / S del disco SQLite

Cuando uso Subversion en Cygwin para actualizar algunos repositorys, algunos directorys se actualizan con éxito, mientras que otros obtienen un error con el post de error:

svn: E200030: sqlite: error de E / S del disco

Al hacer svn update nuevamente para el mismo repository, un directory diferente puede get el mismo error. A veces, hay una instrucción SVN después del post de error anterior.

Esto sucedió debido a un cambio que alguien quería en el package SQLite de Cygwin. Yo era el mantenedor de ese package cuando se hizo esta pregunta, y realicé el cambio que causó este síntoma.

El cambio se lanzó como Cygwin SQLite versión 3.7.12.1-1 , y solucionó el problema de una persona, pero tuvo el efecto secundario negativo de impedir que el package de Subversión de Cygwin cooperara con las implementaciones nativas de Windows Subversion.

¿Que pasó?

El problema principal aquí es que Subversion 1.7 cambió el formatting de copy de trabajo en disco . Parte de ese cambio implica un nuevo file de database SQLite, .svn/wc.db Ahora, para implementar las garantías de concurrency de SQLite, SQLite bloquea el file de database mientras lo está accediendo.

Todo está bien y es sensato, pero se encuentra con un problema cuando intenta mezclar la semántica de locking de files nativos y POSIX de Windows. En Windows, el locking de files casi siempre significa un locking obligatorio , pero en los sistemas Linux, que Cygwin está tratando de emular, bloquear significa generalmente un locking de aviso .

Eso ayuda a entender de dónde viene el "error de E / S del disco".

El cambio de Cygwin SQLite 3.7.12.1-1 fue build la biblioteca en "modo Unix" en lugar de "modo Cygwin". En el modo Cygwin, la biblioteca utiliza el locking de files nativo de Windows, lo que va en contra de la filosofía de Cygwin: donde sea posible, los packages Cygwin llaman a las funciones POSIX en lugar de directamente a la API de Windows, para que cygwin1.dll pueda proporcionar la semántica POSIX adecuada.

El locking de files de aviso de POSIX es exactamente lo que desea con SQLite cuando todos los progtwigs que acceden a los DB de SQLite en cuestión están construidos con Cygwin, que es la suposition pnetworkingeterminada dentro de Cygwin. Pero, cuando ejecuta un progtwig de Subversion nativo de Windows como TortoiseSVN junto con un svn POSIX Cygwin puro, se produce un conflicto. Cuando la extensión de shell de TortoiseSVN Windows Explorer tiene el file .svn/wc.db bloqueado con un locking obligatorio y Cygwin svn aparece y testing un locking de aviso, falla inmediatamente. Cygwin svn supone que un bash de locking tendrá éxito inmediatamente o se bloqueará hasta que tenga éxito, por lo que interpreta incorrectamente el error de locking como un error de E / S del disco.

¿Cómo resolvimos este dilema?

Dentro de Cygwin, siempre tratamos de jugar bien con los progtwigs nativos de Windows siempre que sea posible. El truco consistía en encontrar la manera de hacerlo, sin dejar de jugar bien con los progtwigs de Cygwin.

No todos estuvieron de acuerdo en que deberíamos intentar esto. "Cygwin SQLite es parte de Cygwin, por lo que solo necesita funcionar bien con otros progtwigs de Cygwin", diría un grupo. Los contrapartes respondieron: "Cygwin se ejecuta en Windows, por lo que tiene que funcionar bien con otros progtwigs de Windows".

Afortunadamente, se nos ocurrió una forma de hacer felices a ambos grupos.

Como parte del esfuerzo de empaquetado de Cygwin SQLite 3.7.17-x , probé una nueva característica que Corinna Vinschen agregó a cygwin1.dll versión cygwin1.dll . Permitió a un progtwig solicitar el locking obligatorio de files a través de las API de locking de files BSD. Mi parte del cambio fue hacer que Cygwin SQLite active y desactive esta function en la dirección del usuario, permitiendo que el mismo package satisfaga las necesidades tanto de los campamentos centrados en Cygwin como de los nativos de Windows.

Esta característica DLL de Cygwin se mejoró aún más en 1.7.20, y 3.7.13-3 Cygwin SQLite 3.7.13-3 usando la semántica de locking finalizada. Esta versión permitió elegir entre tres estrategias de locking: locking de aviso POSIX, locking de aviso BSD y locking obligatorio BSD / Cygwin. Hasta ahora, la última estrategia ha demostrado ser completamente compatible con el locking nativo de Windows.

Más tarde, cuando Jan Nijtmans asumió el mantenimiento de Cygwin SQLite, mejoró aún más este mecanismo al integrarlo completamente con la capa SQLite VFS . Esto permitió una cuarta opción: el locking nativo de Windows que utilizaba Cygwin SQLite antes de comenzar este viaje. Esto es principalmente una protección contra la posibilidad de que la estrategia de locking de BSD / Windows no coopere limpiamente con un progtwig SQLite nativo de Windows. Hasta donde sé, nadie ha necesitado usar esta opción, pero es bueno saber que está allí.

Remedio alternativo

Si el conflicto que tiene es entre la command-line svn Cygwin y la extensión de shell de TortoiseSVN Windows Explorer, hay otra opción para solucionarlo. TortoiseSVN se envía con progtwigs de command-line nativos de Windows Subversion también. Si los coloca en su PATH delante del directory bin de Cygwin, no debería encontrarse con este problema en absoluto.

Habiendo encontrado el mismo problema, parece (en mi caso al less) ser una interacción con TortoiseSVN. Deshabilitar el caching de icono de estado de TortoiseSVN (Configuraciones> Superposiciones de íconos> Caché de estado "Ninguno"> Aplicar) tiene todo funcionando bien para mí.

(Eso obviamente no resuelve el problema subyacente, que parece deberse al package SQL que el package Subversion de Cygwin necesita para cambiar su modo de acceso. Mientras escribo, hay una discusión activa [si es lenta] en la list de correo de Cygwin sobre cómo para resolver esto.)

ldd /usr/bin/svn muestra que SVN depende de /usr/bin/cygsqlite3-0.dll.

Después de cambiar libsqlite3 de 3.7.12 a 3.7.3, el problema parece desaparecer. Entonces esto puede ser un problema de la biblioteca SQLite .

El uso de TortoiseSVN, marcando Refresh shell overlays en la clean up resolvió el problema para mí.

Para reference de otros, acabo de tener el mismo error ( svn: E200030: sqlite: disk I/O error ) y descubrí que uno de mis files de logging ocupaba todo mi espacio (y no podía escribir en el HDD porque no había ningún espacio).

Ejecutar (para asegurarse de tener suficiente espacio en el disco)

 df -h 

(Si no elimina algunos files grandes (acabo de eliminar algunos files de copy de security y logging)

Entonces solo necesitaba ejecutar:

 svn cleanup 

Esto resolvió el error para mí.