Estaba a punto de diferenciar una copia de seguridad de su fuente para verificar manualmente que los datos son correctos. Algunos caracteres, como åäö, no se muestran correctamente en los datos originales, pero como los clientes (a través de samba) lo interpretan correctamente, no hay de qué preocuparse. Los datos restaurados desde la copia de seguridad muestran los caracteres correctamente, lo que hace que diff no los considere los mismos archivos (con diffs, sino archivos completamente diferentes).
sumas md5, mismo archivo pero nombre diferente.
# md5sum /original/iStock_000003637083Large-barn*
e37c34968dd145a0e25692e1cb7fbdb1 /original/iStock_000003637083Large-barn p? strand.jpg
# md5sum /frombackup/iStock_000003637083Large-barn*
e37c34968dd145a0e25692e1cb7fbdb1 /frombackup/iStock_000003637083Large-barn på strand.jpg
Opciones de montaje y sistemas de archivos
/dev/sdb1 on /original type ext4 (rw,noatime,errors=remount-ro)
/dev/sdc1 on /frombackup type ext4 (rw)
Lugar
LANG=sv_SE.UTF-8
LANGUAGE=
LC_CTYPE="sv_SE.UTF-8"
LC_NUMERIC="sv_SE.UTF-8"
LC_TIME="sv_SE.UTF-8"
LC_COLLATE="sv_SE.UTF-8"
LC_MONETARY="sv_SE.UTF-8"
LC_MESSAGES="sv_SE.UTF-8"
LC_PAPER="sv_SE.UTF-8"
LC_NAME="sv_SE.UTF-8"
LC_ADDRESS="sv_SE.UTF-8"
LC_TELEPHONE="sv_SE.UTF-8"
LC_MEASUREMENT="sv_SE.UTF-8"
LC_IDENTIFICATION="sv_SE.UTF-8"
LC_ALL=
od -c
# ls "/original/iStock_000003637083Large-barn p� strand.jpg" | od -c
0000000 / v a r / w w w / m e d i a b a
0000020 n k e n _ i m a g e s / k u n d
0000040 i d 8 0 / _ B a r n / i S t o c
0000060 k _ 0 0 0 0 0 3 6 3 7 0 8 3 L a
0000100 r g e - b a r n p 345 s t r a
0000120 n d . j p g \n
0000127
# ls "/frombackup/iStock_000003637083Large-barn på strand.jpg" | od -c
0000000 / d a t a / v a r / w w w / m e
0000020 d i a b a n k e n _ i m a g e s
0000040 / k u n d i d 8 0 / _ B a r n /
0000060 i S t o c k _ 0 0 0 0 0 3 6 3 7
0000100 0 8 3 L a r g e - b a r n p 303
0000120 245 s t r a n d . j p g \n
0000135
linux
diff
character-encoding
usuario135361
fuente
fuente
Respuestas:
Los sistemas de archivos Unix tienden a ser independientes de la localidad en el sentido de que los nombres de los archivos consisten en bytes y es asunto de la aplicación decidir qué significan esos bytes si caen fuera del rango ASCII. La convención en Unix hoy es codificar nombres de archivos y todo lo demás en UTF-8, aparte de algunos entornos heredados (principalmente asiáticos). Los sistemas de archivos de Windows, por otro lado, tienden a tener una codificación que se especifica en las propiedades del sistema de archivos.
Si necesita trabajar con nombres de archivo en una codificación diferente, cree una vista traducida de ese sistema de archivos con convmvfs . Consulte cómo trabajar con nombres de archivo en una codificación diferente a través de ssh
Parece que su sistema original tiene nombres de archivo codificados en latin-1. Su sistema actual usa UTF-8, y la secuencia de un byte que representa
å
en latin-1 (\345
) es una secuencia no válida en UTF-8 que sels
imprime como?
. Su proceso de copia de seguridad de alguna manera ha resultado en nombres de archivos codificados en UTF-8. Samba traduce nombres de archivos en función de su configuración.Para acceder a los archivos originales con su codificación nativa, cree una vista recodificada:
(Es posible que necesite otras opciones según los permisos y la propiedad que desee obtener).
fuente
En Unix / Linux, un nombre de archivo puede contener cualquier carácter, excepto
'\0'
(ASCII NUL) y'/'
(barra oblicua, separador de directorio). En particular, si desea dar nombres a sus archivos en Kanji con alguna codificación extraña, simplemente continúe. Probablemente solo verá galimatías enls(1)
u otros comandos, pero no sucederá nada malo. Eso es lo que está viendo,på
se representa comop?
,'?'
aquí hay un atajo común para "carácter desconocido / no ASCII".Intente ejecutar ambos nombres de archivo
od -c
, es decir, haga algo como:(el glob es filtrar nombres no relevantes, ajustar al gusto).
Solo si la salida difiere comenzaría a preocuparme. Pero dada su configuración Svedish, sospecho que el nombre correcto es
på
. ¿Quizás el otro es un nombre en latín-4 sobrante de una configuración anterior?fuente