Desativar o fsck_exfat automático na montagem de volume sujo no Mac OSX

Question

Tenho vários discos rígidos grandes formatados em exFAT para manter a compatibilidade limpa entre o Win7 / Bootcamp e o Snow Leopard.

Aqui está o problema: fsck_exfat precisa de algo como 6-8gb de RAM para completar em um disco grande. (Chkdsk do Windows funciona bem, btw). Se o OSX detectar um volume como sujo, ele parecerá tentar automaticamente fsck do volume ... mas estou descobrindo que ele não corrige nenhum problema. Durante essa varredura automática , o OSX precisa exibir quase tudo para trocar. Eu uso várias unidades externas quando estou em minha escrivaninha em casa, e se um volume exFAT estiver sujo, talvez seja 10 minutos antes que o laptop seja utilizável por unidade , e isso é após Carregador do Finder.

Antes de sugerir o uso de um sistema de arquivos alternativo:

• FAT32 - O limite de arquivo de 4GB é um problema para mim e eu tenho pelo menos uma unidade de 3 TB. Considerando a formatação de volta para isso para as unidades menores
• NTFS - Todo driver OSX NTFS que eu tentei é uma porcaria. ntfs3g é descontroladamente ineficiente com o tempo de CPU e, por algum motivo, freqüentemente congela o todo o sistema por segundos de cada vez durante a E / S pesada. Tuxera NTFS é melhor, mas ainda ruim para uso pesado. Coisas como o Finder gerando miniaturas para uma grande pasta de imagens, ou o uso básico do Songbird em uma biblioteca gerenciada de 300 GB, se tornam extremamente desagradáveis (e frágeis).
• HFS + - O driver HFS que eu uso no Windows (o Paragon que acompanha uma unidade Seagate) corrompeu pelo menos uma pasta importante e me recuso a tocá-la novamente

Pior, eu estava tentando rodar este laptop sem swap, já que estou ficando irritado com o comportamento de troca do OSX (basicamente, ele armazena coisas inativas em disco, independentemente da RAM disponível). O aumento de desempenho de ter o arquivo de swap desativado foi muito bom. MAS! Sempre que fsck for iniciado, automaticamente , o laptop congelará logo em seguida devido à falta de memória RAM.

Isso, é claro, me jogou em um loop: start laptop, OSX vê o suFAT sujo, automaticamente fsck s eles, laptop congela, drives marcados sujos por causa de desligamento ruim, ensaboar, enxaguar, repetir ... não é agradável. Inicializar no Win7 e executar o chkdsk (e encerrar de forma limpa) interrompe esse loop. O swap é reativado por enquanto: - (

A melhor parte é que eu ainda tenho que corrigir manualmente os volumes sujos, porque por qualquer motivo eles montam como somente leitura! Eu só posso desfazer isso depois de eu fsck eu mesmo!

Isso é mais frustrante. Então ... como desabilitar a fsck_exfat automática que é executada em uma montagem exFAT suja? Ou você tem alguma solução alternativa? Eu não me importo com o OSX montando as unidades RO se isso significa que eu mantenho o controle do meu computador (e posso fsck as unidades mais tarde, no meu tempo).

    

Answer 1

Aviso de isenção : não tenho como testá-lo corretamente, mas o seguinte pode lhe dar algum sucesso.

• Desativar o SIP: link
• sudo plutil -replace FSPersonalities.ExFAT.FSRepairExecutable -string "/usr/bin/true" /System/Library/Filesystems/exfat.fs/Contents/Info.plist
• Ativar SIP

Idéia de plano de fundo : Depois de pesquisar o código do kernel XNU para obter referências úteis de como a Apple pode ter implementado esse recurso e analisando o binário exfat_mount no hopper, projetei a substituição de FSRepairExecutable ou FSVerificationExecutable para simplesmente retornar sempre bem-sucedido poderia enfrentar seu desafio.

Aqui está a parte relevante da lista relevante do ExFAT:

  "FSPersonalities" => {
    "ExFAT" => {
      "FSRepairArguments" => "-y"
      "FSVerificationArguments" => "-n"
      "FSFormatMinimumSize" => 1048576
      "FSFormatExecutable" => "newfs_exfat"
      "FSFormatContentMask" => "Windows_NTFS"
      "FSName" => "ExFAT"
      "FSRepairExecutable" => "fsck_exfat"
      "FSMountExecutable" => "mount_exfat"
      "FSMountArguments" => ""
      "FSVerificationExecutable" => "fsck_exfat"
      "FSXMLOutputArgument" => "-x"
      "FSFormatArguments" => ""
      "FSFormatMaximumSize" => 144115188075855872
    }
  }

Como esse arquivo reside na pasta /System , os novos kernels OSX protegem-no usando o SIP. Daí a minúscula solução tediosa descrita acima.

Como alternativa, para permitir edições futuras mais fáceis deste arquivo plist sem comprometer muito sua segurança, você também pode deixar o SIP ativado enquanto desabilita-o para a parte do sistema de arquivos no modo de recuperação:

   csrutil enable --without fs

Considerando que você parece ter lutado até certo ponto com o seu problema, você já pensou em mudar para uma solução de virtualização como Parallels ou VMWare?