Pregunta archivos bloqueados en HFS + partición de inicio compartida entre OSX / Linux


Arranco dual en Arch Linux y OS X 10.6 en mi MacBook Pro. Sincronicé mi UID entre ambos sistemas operativos y creé una partición HFS (sin diario) para usar como una partición compartida de inicio / Usuarios. En su mayor parte funciona como esperaba, pero a veces, cuando arranco en OS X, ciertos archivos están "bloqueados" (cuando obtengo información sobre un archivo en particular, el casillero "Bloqueado" se marca debajo de "General"). Puede resolver el problema anulando manualmente la casilla) y / o obtengo "Operación no permitida" cuando intento eliminar o modificar un archivo. En ambos casos, no veo nada fuera de lo común en los bits de permiso mostrados con ls -l, excepto por un carácter '@' posterior en la posición donde normalmente se produciría el bit adhesivo:

-rw-r--r--@  1 myuser  mygroup   296 Mar 29 11:44 myfile

Este carácter '@' aparece en TODOS los archivos normales, por lo que no parece estar vinculado a la situación de permiso bloqueado / operación sin permiso.

En lo que respecta a Linux, nunca tengo problemas de permisos. Según mi conocimiento y experiencia limitados con ACL, no encontré ninguna ACL en ninguno de los archivos en cuestión.

Por lo que vale, hago la mayor parte de mi edición de archivos usando emacs (Aquamacs en OSX), ¿es posible que esté configurando extraños bits de permisos?

  1. ¿Cuál es la configuración "bloqueada" que usa OS X y tiene un equivalente de bit de permiso (por lo menos, podría desbloquear recursivamente todos los archivos en mi directorio personal desde la terminal)?
  2. ¿Por qué algunos, pero no otros archivos pueden "bloquearse" al iniciar en OS X?
  3. ¿Cuál es el significado del carácter '@'?

4


origen


actualización rápida, acabo de descubrir el comando "chflags" y que el elemento "bloqueado" es el equivalente a configurar / desconectar el indicador uchange, así que puedo usarlo para desbloquear recursivamente mis archivos, pero todavía tengo curiosidad sobre cómo / por qué se están bloqueando en primer lugar. - HazyBlueDot
Considerar deshabilitar los permisos para el volumen: "Además, OS X permite a los usuarios administradores deshabilitar la propiedad y la verificación de permisos para volúmenes removibles por volumen seleccionando Obtener información en el volumen en Finder, luego marcando la casilla" Ignorar la propiedad en este volumen ". (de la documentación de Apple) - ignis


Respuestas:


Me he encontrado con el mismo problema también.

Mi comprensión de la información que he leído aquí, y en otros lugares, es que es un error del kernel de Linux en el módulo hfsplus. Agrega banderas de usuario aleatorias a los archivos. Hay dos indicadores que evitan la edición / eliminación de archivos: uchg y uappnd. Estos son los dos malos. Se pueden aplicar a un archivo o incluso a un directorio principal.

Los indicadores se muestran con:

$ ls -laO / Volumes / my-volume

Los indicadores se pueden eliminar recursivamente con:

$ man chflags

$ chflags -R nouchg, nouappnd, noopaque, dump / Volumes / my-volume

NOTA: elimino también los indicadores opaco y nodump. No necesito banderas.


5



Gran receta, ¡me ayudó! - akauppi


los @ significa que el archivo tiene "atributos extendidos" (metadatos adicionales, abreviado "xattrs") adjuntos en el sistema de archivos. Para ver la lista de xattrs adjunta a los archivos, haga ls -l@ en Mac OS X.

El Mac OS clásico tenía el concepto de "Finder Info", que era un pequeño conjunto de metadatos fijos (no extensibles) que tenían todos los archivos en un volumen HFS. Esto incluía los "códigos de tipo y creador" y los "indicadores de Finder", incluidos el bit "bloqueado", el bit "visible" (oculto) y muchos otros. Mac OS X básicamente ha desaprobado los metadatos del Finder anterior, pero en las ocasiones en que aún es necesario, ahora se adjunta al registro del archivo en el sistema de archivos como xattr. Esos archivos bloqueados que está viendo casi con seguridad tienen esta información de búsqueda xattr adjunta, por lo que el estado del viejo bit "Finder" bloqueado se puede grabar.

Mi sistema Snow Leopard tiene una /usr/bin/xattr comando que parece no tener una página man, pero tiene una declaración de uso si la invocas con -h. Tenga en cuenta que xattr -l filename puede ser útil para obtener un volcado hexadecimal / ASCII de los valores de los xattrs conectados a un archivo.

Los comandos incorporados de Mac OS X para ver y manipular la antigua información de Finder xattr del terminal incluyen GetFileInfo(1) y SetFile(1).

Actualizar:
No tengo una buena explicación de por qué esos archivos están bloqueados, pero mi corazonada es que cualquier software de soporte HFS que esté ejecutando en Linux está malinterpretando el propósito y el estado en desuso del antiguo bit de bloqueo de Finder y configurándolo cuando no debería, o está utilizando intencionadamente el bit de bloqueo como un mecanismo para mapear algún tipo de concepto semántico del sistema de archivos de Linux en HFS.

El bit de bloqueo del Finder estaba pensado como una forma para que los usuarios bloquearan manualmente sus propios archivos para que no los modificaran accidentalmente o los eliminaran, y no significaba un mecanismo para el bloqueo de archivos a nivel de proceso para evitar la escritura de múltiples procesos en el mismo archivo al mismo tiempo. Es decir, no se suponía que fuera un reemplazo para fcntl(2) o flock(2). En el momento en que se diseñó el bit de bloqueo del Finder, el Mac no era un sistema de multiprocesamiento.

Actualización 2: También podría ser que Aquamacs esté abusando del antiguo bit de bloqueo del Finder para llevar a cabo los deseos de bloqueo de archivos de emacs.


3





Encontré una solución. Parece ser una condición de carrera en el módulo kernel hfsplus, causada por el acceso no atómico a userflags. Lo he deshabilitado y las marcas de usuario alguna vez serán cero, desbloqueadas, está bien para mí.

fs / hfsplus / inode.c cerca de la línea 248:

    inode->i_mode = mode;

/* FIXME commented out because of unreliable results, needs mutex_lock (?) */
//    HFSPLUS_I(inode)->userflags = perms->userflags;
    if (perms->rootflags & HFSPLUS_FLG_IMMUTABLE)

fs / hfsplus / catalog.c cerca de la línea 79:

            perms->rootflags &= ~HFSPLUS_FLG_APPEND;

/* FIXME commented out because of unreliable results, needs mutex_lock (?) */
//    perms->userflags = HFSPLUS_I(inode)->userflags;
    perms->mode = cpu_to_be16(inode->i_mode);

Puedes construir un kernel personalizado, pero yo uso dkms:

$ cd /usr/src
$ tar xjpvf linux-source-*.tar.bz2 linux-source-*/fs/hfsplus
$ cp -R linux-source-*/fs/hfsplus hfsplus-YOUR_VERSION
$ vi hfsplus-YOUR_VERSION/inode.c
$ vi hfsplus-YOUR_VERSION/catalog.c
$ vi hfsplus-YOUR_VERSION/dkms.conf (see below for the content)
$ su
# dkms install hfsplus/YOUR_VERSION

/usr/src/hfsplus-YOUR_VERSION/dkms.conf:

NAME=hfsplus
VERSION=YOUR_VERSION
PACKAGE_NAME="$NAME"
PACKAGE_VERSION="$VERSION"
MAKE[0]="make -C ${kernel_source_dir}
  SUBDIRS=${dkms_tree}/${NAME}/${VERSION}/build modules"
BUILT_MODULE_NAME[0]="hfsplus"
DEST_MODULE_LOCATION[0]="/kernel/fs/hfsplus"
REMAKE_INITRD=y
AUTOINSTALL="yes"

Nota: La instalación falla para mí, si no hago un cd en / usr / src.

Para desinstalar:

# dkms remove hfsplus/YOUR_VERSION --all

Medio ambiente: MacBookPro7,1, Core 2 Duo, SATA NVidia MCP89 AHCI, Mac OS X 10.6, Debian GNU / Linux, Kernel 2.6.28, 2.6.29, 3.0, 3.1, 3.2.


3



¿Has informado esto aguas arriba de alguna manera? Creo que me estoy encontrando con el mismo problema. - Blaisorblade
Actualización: el error está solucionado en Linux 3.4. La solución correcta está aquí: git.kernel.org/?p=linux/kernel/git/torvalds/... - Blaisorblade
Guau, primer parche correctivo que he visto como una respuesta SO / SU. Prestigio. - akauppi
@FrankGanske: Solo para aclarar: la solución "funciona", pero es diferente de la oficial y podría tener inconvenientes (supongo que evitaría cambios userflags a propósito, como la respuesta lo reconoce). - Blaisorblade


Este es un error del kernel de Linux, corregido en 3.4 (parche)

He tenido el mismo problema al usar utilidades de Unix puro. A saber, hice una copia de respaldo de mi disco duro Mac OS X de Xubuntu 12.04 en vivo usando rsync. Después de la restauración, muchas carpetas se bloquearon aleatoriamente, incluidos los directorios en repositorios git (y dudo mucho que git lo haya hecho). Puedes ver esos attribs con ls -lO. Hacer eso en mi copia de seguridad muestra que estos bits tienen valores esencialmente aleatorios:

# ls -ldO /Volumes/HFS+Backup/Users/pgiarrusso/*
drwx------   31 pgiarrusso  staff  uchg,nodump,opaque         1054 Aug 13 02:00 /Volumes/HFS+Backup/Users/pgiarrusso/Desktop
drwx------   36 pgiarrusso  staff  nodump                     1224 Jul 22 16:04 /Volumes/HFS+Backup/Users/pgiarrusso/Documents
drwx------  108 pgiarrusso  staff  uappnd                     3672 Aug 13 11:43 /Volumes/HFS+Backup/Users/pgiarrusso/Downloads
drwx------   13 pgiarrusso  staff  uappnd,uchg,opaque          442 Jul 22 05:04 /Volumes/HFS+Backup/Users/pgiarrusso/Dropbox
drwx------   53 pgiarrusso  staff  -                          1802 Aug 12 00:58 /Volumes/HFS+Backup/Users/pgiarrusso/Library
drwx------   11 pgiarrusso  staff  uchg,nodump,opaque          374 Jul 22 17:25 /Volumes/HFS+Backup/Users/pgiarrusso/Movies
drwx------   13 pgiarrusso  staff  uappnd,uchg,nodump          442 Jun 10 12:05 /Volumes/HFS+Backup/Users/pgiarrusso/Music
drwx------   15 pgiarrusso  staff  uappnd,nodump,opaque        510 Jun 10 12:05 /Volumes/HFS+Backup/Users/pgiarrusso/Pictures
drwxr-x---   11 pgiarrusso  staff  opaque                      374 Jul  6 15:33 /Volumes/HFS+Backup/Users/pgiarrusso/Public
drwxr-xr-x   34 pgiarrusso  staff  uappnd,uchg,opaque         1156 May 27 12:39 /Volumes/HFS+Backup/Users/pgiarrusso/Sites
drwxr-xr-x    2 pgiarrusso  staff  uappnd,nodump,opaque         68 Jun 10 21:43 /Volumes/HFS+Backup/Users/pgiarrusso/VirtualBox VMs
-rwxr-xr-x    1 pgiarrusso  staff  uappnd,nodump,opaque       1703 Feb 19  2012 /Volumes/HFS+Backup/Users/pgiarrusso/bash-prompt.sh
drwxr-xr-x   22 pgiarrusso  staff  -                           748 Aug 10 19:47 /Volumes/HFS+Backup/Users/pgiarrusso/bin
lrwxrwxrwx    1 pgiarrusso  staff  nodump,opaque                37 Sep 27  2011 /Volumes/HFS+Backup/Users/pgiarrusso/default.sfx -> /Users/pgiarrusso/opt/rar/default.sfx
-rw-r--r--    1 pgiarrusso  staff  uappnd,uchg          1375563169 Aug  2 18:52 /Volumes/HFS+Backup/Users/pgiarrusso/heapdump-1343925310626.hprof
drwxr-xr-x   22 pgiarrusso  staff  uappnd,nodump               748 Aug  1 22:15 /Volumes/HFS+Backup/Users/pgiarrusso/opt
drwxr-xr-x    7 pgiarrusso  staff  uappnd                      238 Apr 19 20:00 /Volumes/HFS+Backup/Users/pgiarrusso/share
drwxr-xr-x   35 pgiarrusso  staff  nodump,opaque              1190 Aug 10 00:06 /Volumes/HFS+Backup/Users/pgiarrusso/tmp

Lo comparé con el mismo directorio en un sistema de archivos que funciona, y esos bits no están configurados.


1