Tengo un servidor NAS de muestra (QNAP TS-210), con Linux integrado muy limitado (aunque un poco reforzado con Optware/IPKG). Soy un novato en Linux. Después de buscar en Internet, pude escribir mi propio script de respaldo, usando rsync para sincronizar archivos entre el disco duro NAS y unidades USB externas, y con CRON para ejecutar este script periódicamente.
Todo estuvo bien hasta unos días antes. Los correos electrónicos generados por el script de copia de seguridad comenzaron a contener información IO error encountered -- skipping file deletionde muchos recursos (carpetas) de los que se estaba realizando una copia de seguridad. Cuando ejecuto el mismo script a través de SSH, aparecen muchas líneas de error que dicen " cannot send file with empty name in...", seguidas de " rsync error: some files/attrs were not transferred (see previous errors)".
El 100% del contenido del que hago una copia de seguridad proviene de Windows (uso NAS solo para hacer copias de seguridad de mis propias computadoras). Este sistema no permite crear un archivo con nombre vacío. Este problema existe sólo durante unos días y no estuve modificando mis copias de seguridad durante más de algunas semanas (vacaciones). Entonces esto tiene que ser un problema de Linux (integrado en mi NAS).
La pregunta es: ¿qué puede hacer que aparezcan archivos con nombres vacíos? ¿Cómo puedo deshacerme de ellos (cuando voy cda la carpeta mencionada en el informe rsync y lo hago ls -ls, no veo nada como "archivo con un nombre vacío"), por lo que la próxima pasada de rsync terminaría sin tales errores? Y, por último, ¿cómo evitar recibir dichos archivos en el futuro?
Respuesta1
No creo que esto sea culpa de rsync. Creo que has etiquetado correctamente esto como un problema a nivel del kernel, ya que el código relevanteflist.cde las fuentes de rsynclee:
1729 for (errno = 0, di = readdir(d); di; errno = 0, di = readdir(d)) {
1730 unsigned name_len;
1731 char *dname = d_name(di);
...
1746 if (dname[0] == '\0') {
1747 io_error |= IOERR_GENERAL;
1748 rprintf(FERROR_XFER,
1749 "cannot send file with empty name in %s\n",
1750 full_fname(fbuf));
De hecho, esa línea de código fue agregada por el desarrollador rsync.allá por agosto de 2007específicamente para este caso:
If readdir() gives us an empty name, reject it.
En otras palabras, readdir()ella misma (la función del núcleo que devuelve la lista de archivos en un directorio) devolvió una entrada con una cadena vacía. Según las reglas, se supone que eso nunca debe suceder. Citando delEspecificaciones de grupo abierto:
The readdir() function shall not return directory entries containing empty names.
Parece que fue algún tipo de problema transitorio, porque ya no estaba cuando hiciste un lsen ese directorio (que también habría usado readdir(), ya no estaba).
Entonces la respuesta a tus preguntas:
La causa parece ser un sistema de archivos dañado; cualquier cosa, desde un error en el controlador del kernel hasta una falla de hardware, podría ser la responsable.También puede valer la pena verificar si se accede al directorio al que está sincronizando a través de un enlace simbólico o si cruza un límite de red que pueda estar teniendo problemas.
Para deshacerse de ellos: la lista de verificación habitual de reparación del sistema de archivos: fsck, etc.
Para evitarlo en el futuro: supongo que podría decirle a su secuencia de comandos que fuerce una lista recursiva de antemano, pero como ya está siendo notado (y ha regresado de vacaciones), parece que lo correcto es mantener un ojo en y salta sobre la caja si vuelve a suceder.
Espero que esto haya sido útil, ¡buena suerte!