arquivos bloqueados na partição inicial do HFS + compartilhada entre o OSX / Linux

Question

Eu inicializo dual no Arch Linux e OS X 10.6 no meu MacBook pro. Eu sincronizei meu UID entre os dois sistemas operacionais e criei uma partição HFS (sem registro no diário) para usar como uma partição compartilhada de usuários / usuários. Para a maior parte funciona como eu esperava, mas às vezes quando eu sou iniciado no OS X certos arquivos são "bloqueados" (quando eu recebo informações sobre um determinado arquivo a caixa "Locked" é verificada sob o "Geral" Eu posso resolver o problema manualmente desmarcando a caixa) e / ou eu recebo "Operação não permitida" quando tento excluir ou chmod'ing um arquivo. Em ambos os casos não vejo nada fora do comum nos bits de permissão exibidos com ls -l, exceto por um caractere '@' à direita na posição em que o bit pegajoso normalmente ocorreria:

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

Esse caractere '@' é exibido em TODOS os arquivos normais, portanto, não parece estar vinculado à situação de bloqueio / operação e não permissão.

No lado do Linux, nunca tenho problemas de permissão. Para o melhor do meu conhecimento e experiência limitados com as ACLs, não encontrei nenhuma ACL em nenhum dos arquivos em questão.

Por que vale a pena, eu faço a maioria da minha edição de arquivos usando o emacs (Aquamacs no OSX), é possível que esteja configurando bits de permissão estranhos?

1. Qual é a configuração "bloqueada" que o OS X usa e tem um bit de permissão equivalente (então, no mínimo, eu poderia desbloquear recursivamente todos os arquivos em meu diretório pessoal do terminal)
2. por que alguns, mas não outros arquivos, podem ser "bloqueados" ao inicializar no OS X
3. qual é o significado do caractere '@'?

Answer 1

Eu tenho me deparado com o mesmo problema também.

Meu entendimento da informação que eu li aqui, e em outros lugares, é que é um bug do kernel do Linux no módulo hfsplus. Adiciona sinalizadores de usuários aleatórios aos arquivos. Há dois sinalizadores que impedem a edição / exclusão de arquivos: uchg e uappnd. Estes são os dois bandidos. Eles podem ser aplicados a um arquivo ou até mesmo a um diretório pai.

Sinalizadores são exibidos com:

$ ls -laO /Volumes/my-volume

Os sinalizadores podem ser removidos recursivamente com:

$ man chflags

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

NOTA: eu removo também os sinalizadores opacos e nodump. Eu não preciso de bandeiras.

    

Answer 2

O @ significa que o arquivo possui "atributos estendidos" (metadados extras, abreviados como "xattrs") anexados a ele no sistema de arquivos. Para ver a lista de xattrs anexada aos arquivos, faça ls -l@ no Mac OS X.

O clássico Mac OS tinha o conceito de "Informações do Finder", que era um pequeno conjunto de metadados fixo (não extensível) que todos os arquivos em um volume HFS tinham. Isso incluía os "códigos de tipo e criador" e "flags do Finder", incluindo o bit "bloqueado", o bit "visível" (oculto) e vários outros. O Mac OS X basicamente preteriu os antigos metadados do Finder, mas nas ocasiões em que ainda é necessário, ele agora é anexado ao registro do arquivo no sistema de arquivos como um xattr. Esses arquivos bloqueados que você está vendo quase certamente têm esse info xattr do Finder anexado, para que o estado do bit "bloqueado" do Finder antigo possa ser gravado.

O sistema My Snow Leopard tem um comando /usr/bin/xattr que parece não ter nenhuma página man, mas ele tem uma instrução de uso se você invocá-lo com -h . Observe que xattr -l filename pode ser útil para obter um dump hex / ASCII dos valores dos xattrs anexados a um arquivo.

Os comandos incorporados do Mac OS X para visualizar e manipular o antigo xattr de informações do Finder do terminal incluem GetFileInfo(1) e SetFile(1) .

Atualização:
Eu não tenho uma boa explicação para por que esses arquivos estão sendo bloqueados, mas meu palpite é que qualquer software de suporte a HFS que você esteja executando no Linux está entendendo mal o propósito e o status obsoleto do antigo bit de bloqueio do Finder e definindo-o quando ele não deveria, ou está usando intencionalmente o bit de bloqueio como um mecanismo para mapear algum tipo de conceito semântico do sistema de arquivos Linux para o HFS.

O bit de bloqueio do Finder foi planejado como uma maneira de os usuários bloquearem manualmente seus próprios arquivos para que não os modificassem ou apagassem acidentalmente, e não era como um mecanismo para o arquivo em nível de processo bloqueio para evitar vários processos gravando no mesmo arquivo ao mesmo tempo. Ou seja, não deveria ser um substituto para fcntl(2) ou flock(2) . No momento em que o bit de bloqueio do Finder foi projetado, o Mac não era um sistema de multiprocessamento.

Atualização 2: Também pode ser que o Aquamacs esteja abusando do antigo bit de bloqueio do Finder para realizar os desejos de bloqueio de arquivos do emacs.

    

Answer 3

Eu encontrei uma solução alternativa. Parece ser uma condição de corrida no módulo kernel do hfsplus, causada pelo acesso não atômico a flags de usuários. Eu o desabilitei e as flags de usuário serão zero, desbloqueadas, ok para mim.

fs / hfsplus / inode.c perto da linha 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 próxima linha 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);

Você pode criar um kernel personalizado, mas eu uso o 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"

Observação: a instalação falha para mim, se eu não fizer o cd em / usr / src.

Para desinstalar:

# dkms remove hfsplus/YOUR_VERSION --all

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.

    

Answer 4

Este é um bug do kernel do Linux, corrigido em 3.4 ( patch ).

Eu tive o mesmo problema usando utilitários puros do Unix. Ou seja, eu fiz backup do meu disco rígido do Mac OS X do Xubuntu 12.04 ao vivo usando o rsync. Após a restauração, muitas pastas foram aleatoriamente bloqueadas, incluindo diretórios em repositórios git (e eu duvido que o git faria isso). Você pode ver esses atributos com ls -lO . Fazer isso no meu backup mostra que esses bits têm essencialmente valores aleatórios:

# 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

Eu comparei isso com o mesmo diretório em um sistema de arquivos de trabalho, e esses bits não estão configurados.