OSX / Linux間で共有されるHFS +ホームパーティション上のロックされたファイル
MacBookProでArchLinuxとOSX10.6をデュアルブートします。両方のOS間でUIDを同期し、共有ホーム/ユーザーパーティションとして使用するHFSパーティション（ジャーナリングなし）を作成しました。ほとんどの場合、期待どおりに機能しますが、OS Xを起動すると、特定のファイルが「ロック」されることがあります（特定のファイルに関する情報を取得すると、[全般]の下の[ロック]ボックスがオンになります。ペイン。手動でチェックボックスをオフにすることで問題を解決できます）、および/またはファイルを削除またはchmodしようとすると、「操作は許可されていません」と表示されます。どちらの場合も、スティッキービットが通常発生する位置にある末尾の「@」文字を除いて、ls-lで表示される許可ビットに異常なことは何も表示されません。
-rw-r--r--@ 1 myuser mygroup 296 Mar 29 11:44 myfile
この「@」文字はすべての通常のファイルに表示されるため、許可されていないロック/操作の状況にリンクされていないようです。
Linux側では、パーミッションの問題はありません。 ACLに関する私の限られた知識と経験の限りでは、問題のファイルのいずれにもACLは見つかりませんでした。
価値があるので、私はほとんどのファイル編集をemacs（OSXのAquamacs）を使用して行いますが、奇妙な許可ビットを設定している可能性はありますか？
- OS Xが使用する「ロック」設定とは何ですか。また、同等のアクセス許可ビットがありますか（少なくとも、ホームディレクトリ内のすべてのファイルをターミナルから再帰的にロック解除できます）。
- oS Xを起動すると、他のファイルではなく一部のファイルが「ロック」されるのはなぜですか。
- 「@」文字の意味は何ですか？
私も同じ問題に直面しています。
私がここや他の場所で読んだ情報からの私の理解は、それがhfsplusモジュールのLinuxカーネルのバグであるということです。ランダムなユーザーフラグをファイルに追加します。ファイルの編集/削除を妨げる2つのフラグがあります：uchgとuappnd。これらは2人の悪者です。それらはファイルまたは親ディレクトリにさえ適用することができます。
フラグは次のように表示されます。
$ ls -laO/Volumes/my-volume
フラグは、次の方法で再帰的に削除できます。
$ man chflags
$ chflags -R nouchg、nouappnd、noopaque、dump/Volumes/my-volume
注：不透明フラグとnodumpフラグも削除します。フラグは必要ありません。
回避策を見つけました。これは、ユーザーフラグへの非アトミックアクセスが原因で発生したhfsplusカーネルモジュールの競合状態のようです。私はそれを無効にしました、そしてユーザーフラグはゼロになり、ロックが解除され、私にとっては大丈夫です。
248行目近くのfs/hfsplus/inode.c：
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)
79行目近くのfs/hfsplus/catalog.c：
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にcdしないと、インストールは失敗します。
アンインストールするには：
# 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。
_@_は、ファイルに「拡張属性」（追加のメタデータ、「xattrs」と略記）が添付されていることを意味します。ファイルに添付されているxattrのリストを表示するには、Mac OS Xで_ls -l@_を実行します。
Classic Mac OSには、HFSボリューム上のすべてのファイルが持つ小さな固定（拡張不可能）メタデータのセットである「FinderInfo」の概念がありました。これには、「タイプコードと作成者コード」、および「ロック」ビット、「表示」（非表示）ビットなどを含む「ファインダーフラグ」が含まれていました。 Mac OS Xは基本的に古いFinderメタデータを非推奨にしましたが、それがまだ必要な場合は、ファイルシステム内のファイルのレコードにxattrとして添付されるようになりました。表示されているロックされたファイルには、ほぼ確実にこのFinder情報xattrが添付されているため、古いFinderの「ロックされた」ビットの状態を記録できます。
私のSnowLeopardシステムにはmanページがないように見える_/usr/bin/xattr_コマンドがありますが、_-h_で呼び出すと使用法ステートメントがあります。 _xattr -l filename_は、ファイルに添付されたxattrsの値の16進/ ASCIIダンプを取得するのに役立つ場合があることに注意してください。
ターミナルから古いFinder情報xattrを表示および操作するためのMacOS Xの組み込みコマンドには、GetFileInfo(1)およびSetFile(1)が含まれます。
更新：
これらのファイルがロックされる理由についてはよく説明できませんが、Linuxで実行しているHFSサポートソフトウェアが、古いFinderロックの目的と非推奨のステータスを誤解しているのではないかと思います。ビットして、必要のないときに設定するか、ある種のLinuxファイルシステムのセマンティックコンセプトをHFSにマップするメカニズムとして意図的にロックビットを使用しています。
Finderロックビットは、ユーザーが自分のファイルを手動でロックして、誤ってファイルを変更または削除しないようにするためのものであり、ではありません複数のプロセスが同じファイルに同時に書き込むことを回避するためのプロセスレベルのファイルロックのメカニズムとして。つまり、fcntl(2)またはflock(2)の代わりになることは想定されていませんでした。 Finderロックビットが設計された当時、Macはマルチプロセッシングシステムではありませんでした。
更新2： Aquamacsが古いFinderロックビットを悪用してemacsのファイルロック要求を実行している可能性もあります。
これはLinuxカーネルのバグであり、3.4で修正されています（ patch ）。
純粋なUnixユーティリティを使用しても同じ問題が発生しました。つまり、rsyncを使用してXubuntu12.04からMacOSXハードドライブをライブでバックアップしました。復元後、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
これを動作中のファイルシステム上の同じディレクトリと比較しましたが、これらのビットは設定されていません。