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


Я дважды загружаюсь в 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. в чем смысл символа «@»?

4
2018-05-17 16:22


происхождения


быстрое обновление, я только что открыл команду chflags и что «заблокированный» элемент эквивалентен установке / отключению флага uchange, поэтому я могу использовать его для рекурсивного разблокирования моих файлов, но мне все еще интересно узнать, как / почему они заперты в первую очередь. - HazyBlueDot
Рассматривать отключение разрешений для тома: «Кроме того, OS X позволяет администраторам отключать контроль прав собственности и разрешений для съемных томов на основе объема, выбирая Get Info на томе в Finder, а затем установите флажок« Игнорировать право собственности на этот том ». (из документации Apple) - ignis


ответы:


Я тоже сталкивался с тем же вопросом.

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

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

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

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

$ man chflags

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

ПРИМЕЧАНИЕ. Я удаляю также непрозрачные и nodump флаги. Мне не нужны флаги.


5
2017-09-21 15:23



Отличный рецепт - помог мне! - akauppi


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

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

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

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

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

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

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


3
2018-05-17 18:41





Я нашел обходное решение. Это, по-видимому, условие гонки в модуле ядра 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, Kernel 2.6.28, 2.6.29, 3.0, 3.1, 3.2.


3
2017-08-04 12:24



Вы как-то сообщили об этом вверх по течению? Я думаю, что сталкиваюсь с той же проблемой. - Blaisorblade
Обновление: ошибка исправлена ​​в Linux 3.4. Правильное исправление находится здесь: git.kernel.org/?p=linux/kernel/git/torvalds/... - Blaisorblade
Вау, первый корректирующий патч, который я видел как ответ SO / SU. Престижность. - akauppi
@FrankGanske: Просто уточнить: исправление «работает», но отличается от официального и может иметь недостатки (я думаю, это предотвратило бы изменение userflags специально, как признает ответ). - Blaisorblade


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

У меня была такая же проблема с использованием чистых утилит Unix. А именно, я скопировал свой жесткий диск Mac OS X из Xubuntu 12.04 в режиме реального времени с помощью 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

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


1
2017-09-09 15:52