☰

ファイルシステムが汚れている場合、外付け HDD の .Trashes フォルダ内のファイルを安全に削除して fsck を高速化できますか?

tag-icon • tag-icon hard-drive mac unix external-hard-drive
ファイルシステムが汚れている場合、外付け HDD の .Trashes フォルダ内のファイルを安全に削除して fsck を高速化できますか?

exFAT でフォーマットされた新しい HDD を入手し、そこにフォルダーを移動していたのですが、そこにファイルをコピーするためにさらにスレッドを開いたときに何かが破損してしまいました。

障害が発生したディレクトリはわかっています (おそらく数十万のファイルが入っているため、ディレクトリがスタックしています)。ディレクトリを削除しようとしました (Mac の .Trash フォルダに移動さ​​れました)。

しかし、ファイルを消去できませんでした。そこで、プロセスが実行されていないと考え、HDD を取り外しました。

今：

sudo fsck_exfat -q /dev/disk1s2

ファイルシステムが汚れていると報告する

sudo fsck_exfat -gd /dev/disk1s2

./Thrashes/にリストされている長いファイルリストを調べていることがわかります。

外付けHDDのフォルダ

私にできる事は:

rm -r ./Thrashes/*

スラッシュ内のすべてのファイルを削除し、プロセスを高速化するために fsck を再度実行します。

または、ファイル システムが汚れているため、回避して fsck を完了させる方が良いでしょうか?

次のような線も時々見かけます:

Read      offset = 0x000005200000  length = 0x040000

それはエラーを意味しますか、それとも単なる情報ですか?

これは私が取得したログです:

sudo fsck_exfat -gd /dev/disk1s2
Opening /dev/rdisk1s2
(S,"Checking volume.",0)
(S,"Checking main boot region.",0)
7813556224 total sectors; 512 bytes per sector
FAT starts at sector 32768; size 131072 sectors
15260532 clusters starting at sector 163840; 262144 bytes per cluster
Root directory starts at cluster 11
Read      offset = 0x000001000000  length = 0x001000
(S,"Checking system files.",0)
Read      offset = 0x000005240000  length = 0x040000
(S,"Volume name is %1$@.",1)
luigi4T
Found active bitmap; first cluster 2, length 1907567
(S,"Checking upper case translation table.",0)
Read      offset = 0x000005200000  length = 0x040000
Found upcase table; starting cluster 10, length 5836
(S,"Checking file system hierarchy.",0)
Directory /
File      /._.Trashes
Directory /.Trashes
Directory /.fseventsd
Directory /.Spotlight-V100
Directory /.TemporaryItems
Directory /20190318 BackUp
File      /.com.apple.timemachine.donotpresent
File      /._.com.apple.timemachine.donotpresent
File      /._.TemporaryItems
File      /.apdisk
File      /._.apdisk
Read      offset = 0x000005280000  length = 0x040000
Directory /.Trashes/501
File      /.Trashes/._501
Read      offset = 0x000005300000  length = 0x040000
File      /.fseventsd/fseventsd-uuid
File      /.fseventsd/0000000002073ca7
File      /.fseventsd/0000000002089d5c
...
# files I'd like to remove from Thrashes folder, *before* running a files system check again
...
File      /.Trashes/501/WatchDiscovery 10.01.36 AM/backup Jan 21, 2012/Posters_cleaned/mm2219_9_Assassinio_per_cause_naturali.jpg
File      /.Trashes/501/WatchDiscovery 10.01.36 AM/backup Jan 21, 2012/Posters_cleaned/mm2219_imm_Assassinio_per_cause_naturali.jpg
File      /.Trashes/501/WatchDiscovery 10.01.36 AM/backup Jan 21, 2012/Posters_cleaned/mm221_0_Accordi_sul_palcoscenico.jpg
File      /.Trashes/501/WatchDiscovery 10.01.36 AM/backup Jan 21, 2012/Posters_cleaned/mm221_10_Accordi_sul_palcoscenico.jpg
File      /.Trashes/501/WatchDiscovery 10.01.36 AM/backup Jan 21, 2012/Posters_cleaned/mm221_1_Accordi_sul_palcoscenico.jpg
File      /.Trashes/501/WatchDiscovery 10.01.36 AM/backup Jan 21, 2012/Posters_cleaned/mm221_2_Accordi_sul_palcoscenico.jpg
File      /.Trashes/501/WatchDiscovery 10.01.36 AM/backup Jan 21, 2012/Posters_cleaned/mm221_3_Accordi_sul_palcoscenico.jpg
File      /.Trashes/501/WatchDiscovery 10.01.36 AM/backup Jan 21, 2012/Posters_cleaned/mm221_4_Accordi_sul_palcoscenico.jpg

………………

問題がある場合は、Mac OSバージョン1.9.5

答え1

ファイルシステムがダーティな状態でアンマウントされた場合、ファイルシステムのデータ構造に矛盾や破損が残っているかどうかを正確に知る方法はありません。そのため、読み取り/書き込みでマウントするのは安全ではないと考えられます。まったくfsck されて修正されるまでは、ファイルシステムは変更できません。したがって、たとえゴミ箱に移動したファイルを削除するだけであっても、fsck される前にダーティ アンマウントされたファイルシステムを変更することは安全とは見なされません。

関連情報