заблокированные файлы на домашнем разделе HFS +, совместно используемые OSX / Linux
2819
HazyBlueDot
Я выполняю двойную загрузку в 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), возможно, это устанавливает странные биты прав доступа?
Что такое «заблокированный» параметр, который использует OS X и имеет ли он бит разрешения, эквивалентный (так что по крайней мере я мог бы рекурсивно разблокировать все файлы в моем домашнем каталоге из терминала)
почему некоторые, но не другие файлы могут быть заблокированы при загрузке в OS X
что означает символ «@»?
быстрое обновление, я только что обнаружил команду "chflags", и что "заблокированный" элемент эквивалентен установке / снятию флага uchange, так что я могу использовать это для рекурсивной разблокировки моих файлов, но мне все еще интересно, как и почему они запираются в первую очередь.
HazyBlueDot 12 лет назад
0
Рассмотрим [отключение разрешений для тома] (http://developer.apple.com/library/ios/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemDetails/FileSystemDetails.html): «Кроме того, OS X позволяет пользователям с правами администратора отключите проверку владения и разрешений для съемных томов для каждого тома, выбрав «Получить информацию о томе» в Finder, а затем установите флажок «Игнорировать владение этим томом». " (из документации Apple)
ignis 11 лет назад
0
Из информации, которую я читаю здесь и в других местах, я понимаю, что это ошибка ядра Linux в модуле hfsplus. Это добавляет случайные пользовательские флаги к файлам. Есть два флага, которые запрещают редактирование / удаление файлов: uchg и uappnd. Это два плохих парня. Они могут быть применены к файлу или даже к родительскому каталогу.
ПРИМЕЧАНИЕ. Я убрал также флажки opaque и nodump. Мне не нужны флаги.
Отличный рецепт - выручил меня!
akauppi 10 лет назад
1
3
Spiff
The @ means that file has "extended attributes" (extra metadata, abbreviated "xattrs") attached to it in the filesystem. To see the list of xattrs attached to the files, do ls -l@ in Mac OS X.
Classic Mac OS had the concept of "Finder Info" which was a small fixed (non-extensible) set of metadata that all files on an HFS volume had. This included the "type and creator codes", and the "Finder flags", including the "locked" bit, the "visible" (hidden) bit, and several others. Mac OS X has basically deprecated the old Finder meta-data, but on the occasions where it's still needed, it now gets attached to the file's record in the filesystem as an xattr. Those locked files you're seeing almost certainly have this Finder info xattr attached, so that the state of the old Finder "locked" bit can be recorded.
My Snow Leopard system has a /usr/bin/xattr command that seems to have no man page, but it does have a usage statement if you invoke it with -h. Note that xattr -l filename can be useful to get a hex/ASCII dump of the values of the xattrs attached to a file.
Mac OS X's built-in commands for viewing and manipulating the old Finder info xattr from the terminal include GetFileInfo(1) and SetFile(1).
Update: I have no good explanation for why those files are getting locked, but my hunch would be that whatever HFS support software you're running in Linux is either misunderstanding the purpose, and the deprecated status, of the old Finder lock bit and setting it when it shouldn't, or it's intentionally using the lock bit as a mechanism to map some kind of Linux filesystem semantic concept onto HFS.
The Finder lock bit was intended as a way for users to manually lock their own files so they didn't accidentally modify or delete them, and was not meant as a mechanism for process-level file locking to avoid multiple processes writing to the same file at the same time. That is, it was not supposed to be a replacement for fcntl(2) or flock(2). At the time the Finder lock bit was designed, the Mac was not a multiprocessing system.
Update 2: It could also be that Aquamacs is abusing the old Finder lock bit to carry out emacs' file locking wishes.
3
Frank Ganske
Я нашел обходной путь. Похоже, что это состояние гонки в модуле ядра 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.
Чтобы удалить:
# 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.
Вы сообщили об этом как-то вверх по течению? Я думаю, что сталкиваюсь с той же проблемой.
Blaisorblade 11 лет назад
0
Обновление: ошибка исправлена в Linux 3.4. Правильное исправление здесь: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=f3922382ce930e76773fb06416a7a6081a8702ad
Blaisorblade 11 лет назад
0
Вау, первый исправительный патч, который я видел как ответ SO / SU. Престижность.
akauppi 10 лет назад
0
@FrankGanske: Просто чтобы уточнить: исправление «работает», но отличается от официального и может иметь недостатки (я полагаю, что это намеренно предотвратит изменение «пользовательских флагов», как признает ответ).
Blaisorblade 10 лет назад
0
1
Blaisorblade
Это ошибка ядра Linux, исправленная в 3.4 ( патч ).
У меня была та же проблема с использованием чистых утилит Unix. А именно, я зарезервировал свой жесткий диск Mac OS X из Xubuntu 12.04 live, используя rsync. После восстановления многие папки были случайно заблокированы, включая каталоги в репозиториях git (и я очень сомневаюсь, что git сделает это). Вы можете увидеть эти атрибуты с ls -lO. Выполнение этого в моей резервной копии показывает, что эти биты имеют практически случайные значения: