Guías de tecnología · GUÍA PRÁCTICA
Tar dice “file changed as we read it”: audita la ruta antes de ocultar el aviso
Identifica la ruta exacta, conserva el estado original y distingue cambios de directorio de cambios en los datos de la aplicación. Un archivo legible o un aviso oculto no equivalen a un respaldo restaurable.
El mensaje “file changed as we read it” de GNU tar requiere comprobar la ruta, no declarar automáticamente que todo el archivo es inútil o inocuo. En creación, adición o actualización, el código 1 significa que cambiaron archivos y el conjunto no se copió exactamente. Conserva esa prueba antes de modificar la política del trabajo.
1. Registra la ruta y distingue entrada de salida
Guarda comando exacto, versión de GNU tar, directorio de trabajo, raíz, exclusiones, destino, hora y stderr completo. Captura el estado de tar al terminar: otro comando o el último proceso de una tubería puede ocultarlo. Conserva también fallos del compresor o I/O. Un archivo nombrado y el directorio “.” plantean preguntas distintas.
Contrasta el destino con el árbol de entrada. Si creas la salida dentro, muévela a otro destino para una repetición controlada y verifica que siguen incluidos los datos requeridos. Crear un archivo excluido también puede cambiar su directorio padre. No sustituyas el conjunto revisado por un comodín del shell solo para callar el aviso: puede cambiar la selección de archivos ocultos.
2. Clasifica cambios de datos y del sistema de archivos
Pregunta al responsable si la ruta contiene caché desechable, registros activos, recursos estáticos o estado esencial. No excluyas todos los registros, bloqueos o nombres temporales sin una política que permita perderlos. Si se nombra un directorio, inspecciona actividad y capa de archivos o contenedor; no supongas cambios en todos sus hijos. Si persiste en un origen aparentemente estable, guarda versiones y una reproducción pequeña.
El issue original 384 de fuse-overlayfs muestra un límite del diagnóstico simple. Su autor reprodujo el aviso en el directorio raíz con entradas hijas excluidas y lo redujo a un programa que cambiaba la marca temporal observada. El registro recuperado sigue abierto. Ese caso histórico justifica revisar la capa, no demuestra la misma causa en tu contenedor actual ni aporta una solución universal.
3. Obtén un origen coherente antes de aceptar la repetición
Para recursos estáticos, prepara un origen quieto y revisado y no lo actualices mientras tar lee. Para una base activa, usa su procedimiento documentado, no asumas que copiar un directorio basta. PostgreSQL exige apagar el servidor para copia ordinaria o una instantánea correctamente coherente con WAL necesario. Los volúmenes separados necesitan coordinación; bloquear conexiones o repetir copias en vivo no equivale.
Crea un archivo con nombre distinto desde el origen aprobado y conserva salida y estado. Contrasta miembros con el inventario requerido, incluidos ocultos y exclusiones previstas. Cuando corresponda, compara con el origen estable y restaura contenido representativo en un sitio de prueba aislado. Listar no prueba recuperación de la aplicación. Sigue su prueba de restauración para datos con estado y conserva el archivo anterior hasta que el sustituto cumpla requisitos.
4. Trata la supresión como una política aparte
GNU tar documenta --warning=no-file-changed como control del mensaje. --ignore-failed-read cambia cómo fallos de lectura afectan a la finalización y es más amplio que ocultar uno. Ninguno vuelve coherentes datos cambiantes ni recupera omisiones. Revisa la documentación de la versión instalada y el estado real en lugar de copiar arreglos de antiguas versiones de Windows, contenedores o tar.
Acepta el aviso solo con ruta y cambio permitido entendidos, contenido requerido utilizable y otros fallos visibles. No conviertas todo estado no cero en éxito con || true, descartes stderr completo ni interpretes el cero de un envoltorio como listo para restaurar. Si los datos son críticos, la causa no se explica o la restauración falla, mantén el trabajo sin resolver e investiga origen o método de respaldo de la aplicación.
