☰

Primero probando lo contrario:

tag-icon • tag-icon xattr base64
Primero probando lo contrario:

He escrito un breve script de shell que simplemente se ajusta setfattren una forma un poco más conveniente para configurar el atributo extendido que corresponde a un comentario de texto libre:

#!/bin/sh
test "$2" && setfattr -n user.xdg.comment -v "$2" "$1"
getfattr -d -m '^user.xdg.comment$' "$1"

Para almacenar comentarios ASCII de EE. UU. como xattrs, esto funciona muy bien. Sin embargo, si intento establecer un comentario que contenga caracteres ASCII que no sean de EE. UU., me devuelve lo que parecen ser datos codificados en Base64:

$ touch xyz
$ set-comment xyz åäöåä
# file: xyz
user.xdg.comment=0sw6XDpMO2w6XDpA==
$

Pero no se trata sólo de Base64:

$ printf "0sw6XDpMO2w6XDpA==" | \base64 --decode
��:\:L;l:\:@base64: invalid input
$

La mayoría de las veces, obtengojustobasura de aspecto aleatorio. Algunas veces, como esta, el decodificador Base64 me devuelve una "entrada no válida".

¿Qué es esta cuerda?¿Cuál es su relación con el valor de entrada original? ¿Cómo paso de lo que getfattrme devuelve al valor de entrada original (como åäöåäen este caso)?

setfattr --versionen mi sistema responde con setfattr 2.4.46. Estoy ejecutando la versión empaquetada por Debian Wheezy. En el improbable caso de que importe, estoy ejecutando ZFS en Linux 0.6.3 (también vi el mismo comportamiento con 0.6.2) en el kernel original de Wheezy.

Respuesta1

Sentí un poco de curiosidad al leer esta pregunta, así que hagamos algunas“forense”:

Primero probando lo contrario:

¿Cómo se åäöåäcodifica en Base64?

$ echo åäöåä | base64
w6XDpMO2w6XDpAo=

Esto claramente se parece mucho al 0sw6XDpMO2w6XDpA==que tienes. Hay un extra 0sal principio y el final no coincide exactamente. Suprimiendo la nueva línea al final de åäöåä(insertada automáticamente por echo), obtenemos:

$ echo -n åäöåä | base64
w6XDpMO2w6XDpA==

Este es exactamente el user.xdg.commentvalor excepto el 0sdel principio.

Conclusión

El comentarioesBase64 codificado y con el prefijo 0s, y probar algunas otras cadenas lo confirma.

Ejemplo:

$ ./set-comment xyz 日本語
# file: xyz
user.xdg.comment=0s5pel5pys6Kqe

$ base64 -d <<<'5pel5pys6Kqe' ; echo
日本語

(donde el objetivo ; echoes no estropear el siguiente mensaje ya que el resultado de base64no termina en una nueva línea).

Sin embargo...

Esto simplemente muestra que en estos casos (donde el comentario no es ASCII), se codifica en Base64 y tiene el prefijo 0s.

La respuesta "real"

Después de hacer esto, se me ocurrió la espléndida idea de consultar la página de manual getfattry menciona, entre otras cosas:

Respecto a la opción-e en, --encoding=en

Codifique valores después de recuperarlos. Los valores válidos de en son "texto", "hexadecimal" y "base64". Los valores codificados como cadenas de texto están entre comillas dobles ("), mientras que las cadenas codificadas como hexadecimal y base64 tienen el prefijo 0x y 0, respectivamente.

Entonces, cambiando tu script a:

(Archivoset-comentario:)

#!/bin/sh
test "$2" && setfattr -n user.xdg.comment -v "$2" "$1"
getfattr -e text -d -m '^user.xdg.comment$' "$1"

siempre imprimirá el atributo como texto, dando, por ejemplo:

$ ./set-comment xyz åäöåä   # with fixed script
# file: xyz
user.xdg.comment="åäöåä"

Sin embargo, todavía quedan algunas advertencias... como:

$ ./set-comment xyz 0x414243
# file: xyz
user.xdg.comment="ABC"

y

$ ./set-comment xyz 0s5pel5pys6Kqe
# file: xyz
user.xdg.comment="日本語"

donde la salida no coincide con la entrada.

Estos pueden solucionarse “masajeando” el argumento hasta darle la forma que setfattrle guste. Ver man setfattr.

información relacionada