Может ли переключение между Win7 и Win10 (Creators) повредить диск данных, используемый обоими?

Я загружаюсь либо с системного диска Win7, либо с системного диска Win10 с мобильной стойки. Когда я использую любую из ОС, я могу получить доступ к третьему постоянно установленному диску данных. Там никогда не было никаких проблем.

В эти выходные я обновил свой мобильный накопитель Win10 до обновлений Creators и Fall Creators. Я играл в Win10, и все выглядело хорошо.

Затем я переключился на свой диск Win7 и до того, как появилась Windows, захотел проверить целостность диска с данными. Это сделало, но также проверило все диски в моей системе (некоторые диски RAID и SSD, которые в настоящее время все пусты). Chkdsk обнаружил кучу ошибок, о которых я упомяну ниже в другом случае. Я вручную запустил chkdsk на диске с данными с помощью параметров / f / r, и с диском все было в порядке.

Затем я снова переключился на системный диск Win10 и снова захотел проверить целостность данных (и всех) дисков. На этот раз было еще больше проблем с диском данных, и некоторые файлы были даже потеряны. К счастью, диск данных содержит только около 90 ГБ данных. Но вот пример того, что он сообщил:

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 x86_fsplugin07.dll@1.0.0.0 (6605) into directory 
file 3861.
Recovering orphaned file X86_FS~2.0 (6608) into directory file 3861.
Recovering orphaned file x86_FSViewer.exe@1.0.0.0 (6608) into directory file 
3861.
Recovering orphaned file X86_NU~1.0 (6611) into directory file 3861.
Recovering orphaned file X86_Nullsoft.NSIS.exehead@1.0.0.0 (6611) into 
directory file 3861.
Recovering orphaned file X86_YO~1.0 (6614) into directory file 3861.
Recovering orphaned file x86_Your.Application.Name.Here@1.0.0.0 (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>
[...]

Я не помещал никаких данных на другие носители данных в компьютере, чтобы посмотреть, что произойдет, когда я переключаюсь между Win7 и Win10. Но похоже, что в этот момент проблема может быть связана с одним из обновлений Creator до Win10.

Это возможно? Я не могу найти ни одного подобного случая в Интернете.

На диске с данными нет программ. Это просто изображения, фильмы, текстовые файлы и т. Д.

Не зная, что делать, я начал ковыряться. Я заметил, что файлы, которые идентифицировались при принудительном сканировании chkdsk, были недавними файлами. Поэтому я создал новый файл на дисках E (жесткий диск, на котором было большинство проблем), G: (SSD) и R: (RAID-массив LSI). Я также переименовал файл на диске F: (SSD). Я сделал это под управлением Win7 Pro SP1.

Затем я заменил Win7 на мобильную стойку Win10, и в журнале событий снова появились ошибки, такие как «обнаружено повреждение в структуре файловой системы» на диске E: а файлы, созданные на всех упомянутых выше дисках, не были видны. И файл, который я переименовал, все еще показывал оригинальное имя, а не новое имя.

Так что я несколько раз переходил от Win7 к Win10 к Win7. Я обнаружил ошибки при использовании sfc / scannow на диске Win7, но не на Win10. Я не видел новые файлы, которые создал на диске с данными, когда впервые переключился на Win10. В конце концов я увидел новые файлы при запуске Win10 на дисках E: и G: и это, вероятно, потому, что chkdisk исправил файловую структуру. Но я до сих пор не видел новый файл на RAID-массиве R :. Когда я снова переключаюсь на Win7, я вижу это. И файл, который я изменил, никогда не обновлялся. Под Win10 он показывает оригинальное имя, прежде чем я переименовал его под Win7.

Повреждение все еще происходит между двумя операционными системами, но я начинаю думать, что Win7 Pro может быть проблемой. Очевидно, что существует проблема записи и чтения через операционные системы на общий диск, но я не знаю, в чем проблема. Я действительно надеялся, что Scannow это исправит.