gparted congelar durante a redimensionamento da partição NTFS

Question

Como mencionado no título, Gparted congelou enquanto mudava uma partição NTFS para a esquerda e aumentava de tamanho para preencher o espaço em disco à direita.

A última operação que estava realizando foi movendo setores com um tamanho de bloco de 16Mb.

Existe alguma maneira de eu conseguir retomar a movimentação ou fazer manualmente o resto? Para um exemplo do que quero dizer, veja este post: link

EDIT: Eu descobri agora as seguintes informações:

• O setor exato em que a operação de cópia foi interrompida é no. 2,529,216,511.
• De acordo com o MBR do disco, o primeiro setor da partição é de 202.390 MiB desde o início do disco e tem um comprimento de 1.705.337 MiB - que é o que eu deveria ter.
• O BPB estendido na partição NTFS afirma que o tamanho da partição é de 1.293.319 MiB. Isso está errado e presumivelmente deveria ter sido atualizado quando a cópia foi concluída.

Answer 1

OK, então finalmente consertei isso!

Esta solução também deve funcionar para outros sistemas de arquivos se o GParted fizer a mesma 'cópia direta'. Obviamente, você precisará usar algo diferente de chkdsk no final.

De qualquer forma, aqui está o procedimento para resolver o problema para o benefício de qualquer um que seja tão desafortunado / estúpido * quanto eu:

1. Antes de começar, relaxe - vá buscar um café ou uma caneca de chocolate quente!

   Seus dados ainda estão no disco, você só precisa procurá-los. Passar tempo calmamente checando as coisas não vai prejudicá-lo. Correr e ser impulsivo pode.

2. Leia isto cuidadosamente e certifique-se de entender cada etapa. Se você decidir seguir estas instruções, provavelmente é uma boa ideia fazer um backup em um disco separado usando dd . É fácil cometer erros e um backup oferece uma rede de segurança.

3. Certifique-se de anotar qualquer informação sobre a última coisa que o GParted estava fazendo. Você vai querer saber até onde a operação de cópia ficou (o mais preciso possível) e até onde ela foi copiada para trás.

4. Calcule o local exato onde a cópia foi concluída. Eu escrevi dois scripts Python para ajudar nisso, mas eles só foram testados no Ubuntu (definitivamente não funcionarão no Windows) e precisam ser modificados para o seu caso específico .

   • Primeiro, use isso para encontrar um único setor correspondente no disco: findDuplicateSector.py

   • Use isso para encontrar o último setor correspondente (ou seja, onde a operação foi interrompida): findCopyInterruptLocation.py

   • Leia o código e certifique-se de entendê-lo. Eu testei rapidamente, mas pode haver bugs. Todos os números fornecidos são offsets absolutos desde o início da partição / arquivo, ou seja, o offset 0 é o primeiro setor na partição e offset n é o setor n + 1 ^th .

5. Use dd ou algo semelhante para concluir a operação de cópia, tomando cuidado para não confundir os deslocamentos de entrada e saída. Aqui está a sintaxe para dd :

   sudo dd bs=512 skip=<input_offset> if=<partition> seek=<output_offset> of=<partition> count=<num_sectors_to_copy>
   

   Esta etapa levará um tempo longo (levou 8 horas). Se você quiser ver como está progredindo, execute isso em um terminal separado e dd lhe dará uma atualização sobre seu progresso em sua própria janela de terminal:

   sudo kill -s USR1 <PID_of_dd>
   

6. Verifique o seguinte e corrija se necessário:

   • As entradas da tabela de partições do Registro mestre de inicialização (MBR) devem corresponder ao que você disse ao GParted (consulte o artigo da wikipedia, é muito informativo). Especificamente, verifique o valor para o LBA do primeiro setor da partição e seu número total de setores.

   • O Registro de Inicialização da Partição da partição que você está modificando deve corresponder ao MBR (no meu caso, não). Para NTFS, o tamanho total da partição em setores deve estar no deslocamento 40 desde o início da partição. Eu não acho que o NTFS registra o que o deslocamento da partição em relação ao início do disco é.

7. Execute chkdsk no modo somente leitura , ou seja, sem argumentos de linha de comando diferentes do nome da unidade para verificar se ele pode localizar todos os arquivos na partição. Se não for possível verificar os índices do arquivo, NÃO continue . Não se preocupe se ele reclamar do arquivo $ Bitmap contendo erros.

8. Se, e somente se a etapa 5 for bem-sucedida, execute chkdsk /f para corrigir, por exemplo, o arquivo $ Bitmap. Se você executar isso enquanto os índices de arquivos ainda estiverem errados, poderá acabar excluindo-os, tornando as coisas muito mais difíceis para você.

9. Você pode querer executar chkdsk no modo somente leitura novamente para ter certeza de que funcionou, apenas para sua tranquilidade.

_{* Na verdade eu sou muito arrogante - não somos idiotas. Mas sério - faça backups!}

    

Answer 2

Este é um feedback para futuros usuários que se deparam com esse problema. Eu também encontrei este link link

Eu tive esse problema ou um problema muito parecido, mas não consegui corrigi-lo o mais rápido possível devido à questão da vida privada, o GParted não estava fazendo nada por 7-8 dias e depois começou a mover os dados ...

Basta olhar para o tempo de operação de movimentação de 201 horas. No entanto, o não como a maioria dos dados são agora corruptos ... E provavelmente irrecuperável. Obrigado GParted