FAT32形式EFIパーティション周りの不具合報告スレ

[RaMaTcH]

macOSでのFAT形式の取り扱いでちょくちょく不具合を聞くので、情報交換できればと思いスレッドを開設してみます。

[RaMaTcH]

まず自分の方から1点。

(1)ドライブAのEFIをマウント
(2)ドライブBのEFIをマウント
(3)ドライブBのEFI/EFI/CLOVER/config.plistを開くと、なぜかAのが開かれる
(4)おかしいと思ってCloverConfigurator以外のアプリを使って開いても同様
(5)保存せずBのconfig.plistデスクトップにコピーすると、その内容はちゃんとBのconfig.plist

・・・つまりOSがアプリにウソのファイルを引き渡している？？？

[RaMaTcH]

書き漏れましたが、OSはSonomaの14.6.1です。
ただしMontereyなどもっと以前から、config.plistを開いた時に「あれ？なぜこんな内容？」みたいな肩透かしを喰らったことがちょくちょくありました。

時間があれば深堀りしていきたいと思います。

[RaMaTcH]

【検証1-2】config.plistではなくて「test.txt」を作って同様実験
(1)ドライブAのEFIをマウント
(2)ドライブBのEFIをマウント
(3)ドライブAのEFI直下に「test1」という内容のtest.txtを作成
(4)ドライブBのEFI直下に上記ファイルをコピー
(5)ドライブAのtest.txtの内容を「test2」へと書き換え保存
(6)ドライブBのtest.txtの内容を開くと、「test1」のはずが「test2」になっている
(7)ドライブBのtest.txtをFinderでデスクトップにコピーすると、内容は本来の期待通り「test1」で開かれる

結論：FinderはBのファイルを開く操作なのにOSがアプリに対しAのファイルを引き渡している

【検証1-3】検証1-2に対して、ドライブBではなくコンテナCに「EFI」という名前のボリュームを作って同様実験
→正常

[hamagen]

現状のSequoia(RC版)においては、EFIパーティションをマウントすると、ラベル名が「EFI」から「NO NAME」に書き換わってしまいます。
Sequoia beta5ではマウント失敗事例も現認され、beta6以降では実害を認識していませんが、EFIへの操作に対して一抹の不安が拭いきれません。

[投稿者]

投稿