Чому Windows Search "Параметри індексування" вибирає неправильний диск, якщо він клонований?

Я клонував жорсткий диск Windows 10 до SSD Samsung, використовуючи "Software Data Migration Software". Потім я встановив нову копію Windows 10 на SSD. SSD тепер C: і HDD є D :. У Панелі керування, Параметри індексування, Змінити, будь-яку папку, яку я додаю для C: вибирає D :. Наприклад, я виберу C: Windows, натисніть OK, потім знову натискайте Modify - і це D: Windows, що вибрано. Або, якщо я виберу папку, яка не існує в D :, наприклад C: util, вона додає запис типу "D: use (unavailable)".

Щось збиває з пантелику параметри пошуку та індексування Windows через клоновані диски. Дивлячись у реєстрі, я бачу такі записи: [HKEY_LOCAL_MACHINE, ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ] Microsoft Windows Пошук CrawlScopeManager "URL" = "файл: /// C: [9a6b2440-0cb7-4d60-a957-7a1682cf61c4] WINDOWS \ t

Це може бути GUID після "C:", що змішує параметри індексування. Але цей GUID не відображається ніде в реєстрі, окрім "Windows Search". За допомогою Mountvol не можна бачити унікальний ідентифікатор тома, і це не ідентифікатор GPT (або тип розділу), який можна побачити за допомогою Diskpart.

Примітка - інші випробовували таку саму проблему (у Windows 8 також), див.

https://social.technet.microsoft.com/Forums/office/en-US/5381142e-12aa-47da-bae2-18e6d35f414f/issue-with-indexing-in-windows-confusing-c-disk-with-d- disk-need-to-change-sid? forum = w8itproinstall

https://social.technet.microsoft.com/Forums/en-US/bd2b31ea-4bf4-4271-886c-47131cc1b6c8/why-does-the-search-indexer-in-windows-10-insist-on-indexing- - неправильний розділ? forum = win10itprogeneral

https://social.technet.microsoft.com/Forums/en-US/ba7da25d-5754-42ee-a55e-c4b38d27f2fd/i-have-a-problem-with-windows-10-search-indexing?forum=win10itprogeneral

http://answers.microsoft.com/en-us/windows/forum/windows_10-win_cortana/windows-10-indexing-selects-wrong-drive/685ec87b-e7f3-454b-89c9-c485b94bb69d

http://answers.microsoft.com/en-us/windows/forum/windows_10-files/windows-10-indexing-problem/6aea5879-6d13-4a67-b30a-ab255a92ee0c

— Jon
джерело

Перш за все я можу відтворити вашу проблему:

Проблема викликана системним файлом \System Volume Information\IndexerVolumeGuid у кожному з клонованих обсягів. Очевидно, ви маєте рацію, що система плутається з GUID, які ви бачите в тих записах реєстру, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Search\CrawlScopeManager\Windows\SystemIndex\*, і цей файл повинен бути провайдером GUID.

Оскільки томи клоновані, цей конкретний файл ідентичний кожному з них так само, як і інші файли. І він НЕ отримуватиме "оновлення" (тобто не буде відновлено, щоб уникнути конфліктів), коли томи монтуються, як і серія томів:

Однак, мабуть, цей файл безпечний для видалення, і після того, як об'єм буде знову встановлено, буде згенеровано новий. проблема зникне після того, як всі томи, які належать дубльованому GUID, переставляються з унікальними GUID (тому перезавантаження може знадобитися, якщо воно включає поточний обсяг системи):

На жаль, я не впевнений, що є зручний / безпечний спосіб видалити його під Windows:

— Tom Yan
джерело

Вражає. Як ви зрозуміли це?

— Jon

Я тестував і перевертав інформацію про NTFS (метадані, метафайли ...), і нічого не знайшов. А потім я подумав, що я повинен перевірити FAT32 і подивитися, чи поводяться речі по-іншому, і вони не зробили цього. Тому я вважаю, що це пов'язано з деяким прихованим системним файлом, який можна знайти на обох типах файлових систем.

— Tom Yan

Гаразд, перевіримо, що це так, коли я повернуся до свого ПК, щоб прийняти вашу відповідь. Отже, FAT32 не має еквівалента "унікального ідентифікатора обсягу NTFS"? Він як і раніше здається дефектом дизайну - тобто, він повинен використовувати функцію NTFS, коли він там, в іншому випадку не вдасться повернутися до прихованого системного файлу GUID. Дозволяє видаляти його за допомогою права власності та зміни прав доступу.

— Jon

volume unique id ( mountvol X: /L ) не має нічого спільного з файловою системою, але тільки з розділом (таблицею). Для диска GPT Windows використовує unique partition GUID як volume unique id. Для диска MBR використовується ідентифікатор диска ( uniqueid в diskpart ) і початкове положення розділу для формування volume unique id. І FAT32, і NTFS є volume serial; це тільки один з NTFS технічно довше ( fsutil fsinfo ntfsinfo X:, але якщо ви перевіряєте з dir X: Показано лише частину послідовності NTFS, ймовірно, для сумісності з більш коротким FAT32 послідовним).

— Tom Yan

Так чи інакше Microsoft вважає за краще не використовувати будь-який з серійних / ідентифікаторів для свого індексатора, а випадково генерує інший і зберігає його в прихованому системному файлі (якщо він ще не існує), коли монтується. Я не впевнений, що його можна назвати недоліком дизайну. Це просто Microsoft, здається, не вважає "клонування" православна річ, щоб зробити. (Але, принаймні, Windows регенерує ці GUID на таблиці розділів для вас.)

— Tom Yan