заблокированные файлы на домашнем разделе HFS+, совместно используемые OSX/Linux

Question

Я выполняю двойную загрузку в Arch Linux и OS X 10.6 на моем MacBook Pro. Я синхронизировал свой UID между обеими операционными системами и создал раздел HFS (без ведения журнала) для использования в качестве общего раздела home/Users. По большей части это работает так, как я ожидал, но иногда, когда я загружаюсь в OS X, некоторые файлы "блокируются" (когда я получаю информацию о конкретном файле, флажок "Заблокировано" устанавливается под "Общие"). панель. Я могу решить проблему, сняв флажок вручную) и / или я получаю "Операция не разрешена", когда я пытаюсь удалить или chmod'ing файл. В обоих случаях я не вижу ничего необычного в битах разрешений, отображаемых с помощью ls -l, за исключением завершающего символа '@' в той позиции, где обычно происходит бит закрепления:

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

Этот символ '@' отображается на ВСЕХ обычных файлах, поэтому, похоже, не связан с ситуацией заблокированных / операций, а не разрешений.

Что касается Linux, у меня никогда не было проблем с разрешениями. В меру моих ограниченных знаний и опыта работы с ACL я не нашел ни одного ACL ни в одном из рассматриваемых файлов.

Для чего это стоит, я делаю большую часть своего редактирования файлов, используя emacs (Aquamacs в OSX), возможно, это устанавливает странные биты прав доступа?

1. Что такое "заблокированный" параметр, который использует OS X и имеет ли он бит разрешения, эквивалентный (так что по крайней мере я мог бы рекурсивно разблокировать все файлы в моем домашнем каталоге из терминала)
2. почему некоторые, но не другие файлы могут быть заблокированы при загрузке в OS X
3. что означает символ «@»?

Answer 1

Я тоже столкнулся с той же проблемой.

Из информации, которую я читаю здесь и в других местах, я понимаю, что это ошибка ядра Linux в модуле hfsplus. Это добавляет случайные пользовательские флаги к файлам. Есть два флага, которые запрещают редактирование / удаление файлов: uchg и uappnd. Это два плохих парня. Они могут быть применены к файлу или даже к родительскому каталогу.

Флаги отображаются с:

$ ls -laO / Объемы / Мой объем

Флаги могут быть удалены рекурсивно с помощью:

$ man chflags

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

ПРИМЕЧАНИЕ. Я убрал также флажки opaque и nodump. Мне не нужны флаги.

Answer 2

Я нашел обходной путь. Похоже, что это состояние гонки в модуле ядра hfsplus, вызванное неатомарным доступом к пользовательским флагам. Я отключил это, и пользовательские флаги будут когда-либо равны нулю, разблокированы, хорошо для меня.

fs/hfsplus/inode.c возле строки 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 рядом со строкой 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);

Вы можете собрать собственное ядро, но я использую 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"

Примечание: установка завершится неудачно для меня, если я не перейду в /usr /src.

Чтобы удалить:

# dkms remove hfsplus/YOUR_VERSION --all

Среда: MacBookPro7,1, Core 2 Duo, SATA NVidia MCP89 AHCI, Mac OS X 10.6, Debian GNU/Linux, Ядро 2.6.28, 2.6.29, 3.0, 3.1, 3.2.

Answer 3

Символ @ означает, что файл имеет "расширенные атрибуты" (дополнительные метаданные, сокращенно "xattrs"), прикрепленные к нему в файловой системе. Чтобы увидеть список xattrs, прикрепленных к файлам, выполните ls -l@ в Mac OS X.

Классическая Mac OS имела концепцию "Finder Info", которая представляла собой небольшой фиксированный (не расширяемый) набор метаданных, который был у всех файлов на томе HFS. Сюда входят "коды типов и создателей", а также "флаги Finder", в том числе "заблокированный" бит, "видимый" (скрытый) бит и некоторые другие. Mac OS X в основном не поддерживает старые метаданные Finder, но в тех случаях, когда они все еще необходимы, теперь они присоединяются к записи файла в файловой системе как xattr. К тем заблокированным файлам, которые вы видите, почти наверняка прикреплен этот xattr информации Finder, так что состояние старого заблокированного бита Finder может быть записано.

В моей системе Snow Leopard есть команда /usr/bin/xattr которая, похоже, не имеет справочной страницы, но она имеет оператор использования, если вы вызываете ее с -h . Обратите внимание, что xattr -l filename может быть полезно для получения дампа в шестнадцатеричном /ASCII-значении значений xattrs, прикрепленных к файлу.

Встроенные команды Mac OS X для просмотра и управления старым информационным xattr Finder из терминала включают GetFileInfo(1) и SetFile(1) .

Обновить:
У меня нет хорошего объяснения, почему эти файлы блокируются, но я догадываюсь, что любое программное обеспечение, поддерживающее HFS, которое вы используете в Linux, либо неправильно понимает цель и устаревший статус старого бита блокировки Finder и устанавливает его, когда он не должен или намеренно использует бит блокировки в качестве механизма для отображения какой-либо семантической концепции файловой системы Linux на HFS.

Бит блокировки Finder был предназначен для того, чтобы пользователи могли вручную блокировать свои собственные файлы, чтобы они не могли случайно изменить или удалить их, и не предназначался как механизм блокировки файлов на уровне процессов, чтобы избежать записи нескольких процессов в один и тот же файл. в то же время. То есть он не должен был заменять fcntl(2) или flock(2) . В то время, когда был разработан бит блокировки Finder, Mac не был многопроцессорной системой.

Обновление 2: Возможно, Aquamacs использует старый бит блокировки Finder для выполнения желаний блокировки файлов emacs.

Answer 4

Это ошибка ядра Linux, исправленная в 3.4 (патч).

У меня была та же проблема с использованием чистых утилит Unix. А именно, я зарезервировал свой жесткий диск Mac OS X из Xubuntu 12.04 live, используя rsync. После восстановления многие папки были случайно заблокированы, включая каталоги в репозиториях git (и я очень сомневаюсь, что git сделает это). Вы можете увидеть эти атрибуты с помощью ls -lO . Выполнение этого в моей резервной копии показывает, что эти биты имеют практически случайные значения:

# 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

Я сравнил это с тем же каталогом в рабочей файловой системе, и эти биты не установлены.