A comutação entre Win7 e Win10 (Creators) corrompe um disco de dados usado por ambos?

0

Eu inicializo a partir de uma unidade do sistema Win7 ou de uma unidade do sistema Win10 a partir de um rack móvel. Quando estou usando um sistema operacional, posso acessar uma terceira unidade de dados instalada permanentemente. Nunca houve nenhum problema.

Neste fim de semana, atualizei minha unidade móvel Win10 para as atualizações de Criadores e Criadores de outono. Eu brinquei no Win10 e tudo parecia bem.

Então eu mudei para a minha unidade Win7 e antes do Windows aparecer, queria fazer uma verificação de consistência da unidade de dados. Ele fez, mas também fez uma verificação de todas as unidades do meu sistema (algumas unidades de RAID e SSD, que estão atualmente vazias). Chkdsk encontrou um monte de erros que vou mencionar abaixo em outro caso. Eu executei chkdsk manualmente na unidade de dados usando as opções / f / r, e o disco estava bem.

Em seguida, voltei para a unidade do sistema Win10 e, novamente, queria executar uma verificação de consistência nas unidades de dados (e em todas). Desta vez, houve ainda mais problemas com a unidade de dados e alguns arquivos foram perdidos. Felizmente, a unidade de dados tem apenas cerca de 90 GB de dados. Mas aqui está uma amostra das coisas que relatou:

CHKDSK is verifying files (stage 1 of 3)...
Deleted corrupt attribute list entry
with type code 144 in file 9.
Unable to locate attribute of type 0x90, lowest vcn 0x0,
instance tag 0x7 in file 0xec7.
Deleted corrupt attribute list entry
with type code 160 in file 9.
Unable to locate attribute of type 0xa0, lowest vcn 0x0,
instance tag 0x9 in file 0xec7.
Deleted corrupt attribute list entry
with type code 160 in file 9.
Unable to locate attribute of type 0xa0, lowest vcn 0x0,
instance tag 0x6 in file 0xec7.
Deleted corrupt attribute list entry
with type code 176 in file 9.
Unable to locate attribute of type 0xb0, lowest vcn 0x0,
instance tag 0x8 in file 0xec7.
Unable to locate attribute with instance tag 0xf and segment
reference 0x27000000000ec7. The expected attribute type is 0x90.
Deleting corrupt attribute record (144, $SDH)
from file record segment 3783.
Unable to locate attribute with instance tag 0x11 and segment
reference 0x27000000000ec7. The expected attribute type is 0xa0.
Deleting corrupt attribute record (160, $SDH)
from file record segment 3783.
[...]
CHKDSK is verifying indexes (stage 2 of 3)...
The index bitmap for index $SII in file 0x9 is invalid or missing.
The index bitmap for index $SII in file 0x9 is invalid or missing.
The index bitmap for index $SII in file 0x9 is invalid or missing.
The index bitmap for index $SII in file 0x9 is invalid or missing.
Correcting error in index $SII for file 9.
The index bitmap $SII is present but there is no corresponding
index allocation attribute in file 0x9.
Correcting error in index $SII for file 9.
The down pointer of current index entry with length 0x30 is invalid.
14 00 14 00 00 00 00 00 30 00 04 00 01 00 00 00 ........0.......
44 01 00 00 54 7d 23 ff 44 01 00 00 20 3c 00 00 D...T}#.D... <..
00 00 00 00 d4 00 00 00 ff ff ff ff ff ff ff ff ................
14 00 14 00 00 00 00 00 30 00 04 00 01 00 00 00 ........0.......
Sorting index $SII in file 9.
Unable to locate the file name attribute of index entry Then using VE - 
Drive_CD checked.png
of index $I30 with parent 0x34 in file 0x19cb.
Deleting index entry Then using VE - Drive_CD checked.png in index $I30 of 
file 52.
Unable to locate the file name attribute of index entry THENUS~2.PNG
of index $I30 with parent 0x34 in file 0x19cb.
Deleting index entry THENUS~2.PNG in index $I30 of file 52.
The index bitmap $I30 in file 0x46 is incorrect.
Correcting error in index $I30 for file 70.
The file reference 0xf56000000000f55 of index entry 0x6DEC0471FF0A7A4A of 
index $I30
with parent 0xc4 is not the same as 0x19000000000f55.
Deleting index entry 0x6DEC0471FF0A7A4A in index $I30 of file 196.
The file reference 0xf56000000000f55 of index entry 0X6DEC~1 of index $I30
with parent 0xc4 is not the same as 0x19000000000f55.
Deleting index entry 0X6DEC~1 in index $I30 of file 196.
Unable to locate the file name attribute of index entry T2886E~1.MRI
of index $I30 with parent 0xc0a in file 0x19c7.
[...]
CHKDSK is scanning unindexed files for reconnect to their original 
directory.
Recovering orphaned file Chkdsk20171030081425.log (49) into directory file 
18.
Recovering orphaned file MANIFE~1 (3922) into directory file 3861.
Recovering orphaned file Manifests (3922) into directory file 3861.
Recovering orphaned file 670006~2.BIN (3924) into directory file 7424.
Recovering orphaned file 
6700069d9d4e5c7145e1aa8fc78892f0_fce8395c8fd8a98f_c96174849e9e4520_0_0.bin 
(3924) into directory file 7424.
Recovering orphaned file $IBLNG~1.MRI (3926) into directory file 2878.
Recovering orphaned file $IBLNGCR.mrimg (3926) into directory file 2878.
Recovering orphaned file CHROME~1.LOG (3927) into directory file 70.
Recovering orphaned file chrome_installer.log (3927) into directory file 70.
Recovering orphaned file DRIVE_~1.PNG (6603) into directory file 52.
Recovering orphaned file Drive_CD using VE.png (6603) into directory file 
52.
Recovering orphaned file X86_FS~1.0 (6605) into directory file 3861.
Recovering orphaned file [email protected] (6605) into directory 
file 3861.
Recovering orphaned file X86_FS~2.0 (6608) into directory file 3861.
Recovering orphaned file [email protected] (6608) into directory file 
3861.
Recovering orphaned file X86_NU~1.0 (6611) into directory file 3861.
Recovering orphaned file [email protected] (6611) into 
directory file 3861.
Recovering orphaned file X86_YO~1.0 (6614) into directory file 3861.
Recovering orphaned file [email protected] (6614) into 
directory file 3861.
12 unindexed files scanned. 
Recovering orphaned file !WINDO~1 (7587) into directory file 7588.
Recovering orphaned file !Windows 10 - Test (7587) into directory file 7588.
CHKDSK is recovering remaining unindexed files.
1 unindexed files recovered. 

CHKDSK is verifying security descriptors (stage 3 of 3)...
Creating index $SDH for file 9.
Inserting an index entry with Id 256 into index $SII of file 9.
Inserting an index entry with Id 257 into index $SII of file 9.
Inserting an index entry with Id 258 into index $SII of file 9.
Inserting an index entry with Id 260 into index $SII of file 9.
Inserting an index entry with Id 261 into index $SII of file 9.
Inserting an index entry with Id 262 into index $SII of file 9.
Inserting an index entry with Id 263 into index $SII of file 9.
Inserting an index entry with Id 264 into index $SII of file 9.
Inserting an index entry with Id 265 into index $SII of file 9.
Inserting an index entry with Id 266 into index $SII of file 9.
Inserting an index entry with Id 269 into index $SII of file 9.
Inserting an index entry with Id 270 into index $SII of file 9.
Inserting an index entry with Id 271 into index $SII of file 9.
Inserting an index entry with Id 272 into index $SII of file 9.
Inserting an index entry with Id 273 into index $SII of file 9.
Inserting an index entry with Id 275 into index $SII of file 9.
Inserting an index entry with Id 282 into index $SII of file 9.
Inserting an index entry with Id 283 into index $SII of file 9.
Inserting an index entry with Id 284 into index $SII of file 9.<code>
[...]

Eu não coloquei nenhum dado em nenhuma das outras unidades de dados no computador para ver o que acontece quando alterno entre o Win7 e o Win10. Mas parece que neste momento o problema pode ser devido a qualquer uma das Atualizações do Criador para o Win10.

Isso é possível? Não consigo encontrar nenhum caso como este online.

    
por DillyDop 31.10.2017 / 00:52

1 resposta

0

Nenhum programa está na "unidade de dados". São apenas imagens, filmes, arquivos de texto, etc.

Não sabendo o que fazer, comecei a bisbilhotar. Notei que os arquivos que estavam sendo identificados nas varreduras de chkdsk forçadas eram arquivos recentes. Então eu criei um novo arquivo no Drives E (um disco rígido onde a maioria dos problemas tem sido), G: (um SSD) e R: (um array LSI RAID). Eu também renomeiei um arquivo no Drive F: (um SSD). Eu fiz isso executando o Win7 Pro SP1.

Em seguida, substituí o Win7 pelo rack móvel Win10 e o log de eventos mostrou erros novamente, como "a corrupção foi descoberta na estrutura do sistema de arquivos" na Unidade E: E os arquivos criados em todas as unidades mencionadas acima não estavam visíveis. E o arquivo que eu renomei ainda mostrava o nome original, não o novo nome.

Então eu fui e voltei assim do Win7 para o Win10 para o Win7 algumas vezes. Eu encontrei erros usando sfc / scannow no disco Win7, mas não Win10. Eu não vi os novos arquivos que criei no disco de dados na primeira vez que mudei para o Win10. Eventualmente, vi os novos arquivos ao executar o Win10 em Drives E: e G: e isso é provavelmente porque o chkdisk corrigiu a estrutura do arquivo. Mas eu ainda não vi o novo arquivo na matriz RAID R :. Quando volto para o Win7, vejo-o. E o arquivo que eu mudei o nome nunca foi atualizado. Em Win10, ele mostra o nome original antes de eu renomeá-lo no Win7.

A corrupção ainda está acontecendo entre os dois sistemas operacionais, mas estou começando a achar que o Win7 Pro pode ser o problema. Obviamente, há um problema ao gravar e ler os sistemas operacionais em um disco comum, mas não sei onde está o problema. Eu estava realmente esperando que o scannow pudesse consertar isso.

    
por 31.10.2017 / 23:06