Windows Search “Dizin Oluşturma Seçenekleri” klonlanmışsa neden yanlış sürücüyü seçiyor?


1

"Samsung Veri Taşıma Yazılımı" nı kullanarak Windows 10 HDD’yi Samsung SSD’ye kopyaladım. Daha sonra SSD'ye yeni bir Windows 10 kopyası yükledim. SSD şimdi C: ve HDD D: dir. Denetim Masası'ndaki Dizin Oluşturma Seçenekleri, Değiştir, C: \ için eklediğim herhangi bir klasör aslında D: öğesini seçer. Örneğin, C: \ Windows’u seçeceğim, Tamam’a basıp ardından Yeniden Değiştir’e basacağım - seçili olan D: \ Windows. Veya C: \ util gibi D: 'de olmayan bir klasör seçersem, "D: \ util \ (mevcut değil)" gibi bir giriş ekler.

Bir şey klonlanmış sürücüler nedeniyle Windows Arama ve Dizin Oluşturma Seçeneklerini karıştırıyor. Kayıt defterine bakarken aşağıdaki girişleri görebilirim: [HKEY_LOCAL_MACHINE \ YAZILIM \ Microsoft \ Windows Search \ CrawlScopeManager \ Windows \ SystemIndex \ DefaultRules \ 12] "URL" = "file: /// C: \ [9a6b2440-0cb7-4d60-a957-7a1682cf61c4] \ WINDOWS \"

Dizin Oluşturma Seçeneklerini karıştıran "C: \" den sonra GUID olabilir. Ancak bu GUID, "Windows Search" altındaki kayıt defterinde başka hiçbir yerde görünmüyor. Mountvol kullanılarak görülebilen birimin benzersiz tanıtıcısı değildir ve Diskpart kullanılarak görülebilen GPT tanıtıcısı (veya bölüm türü) değildir.

Not - diğerleri de aynı sorunu yaşadı (Windows 8'de de), bkz.

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 ihtiyaç-değişim-sid? forumu = 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- -yanlış-bölüm? forumu = 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

Yanıtlar:


3

Her şeyden önce sorununuzu yeniden oluşturabilirim:

enter image description here

Sorun sistem dosyası tarafından kaynaklanır. \System Volume Information\IndexerVolumeGuid klonlanan hacimlerin her birinde. Görünüşe göre, sistemin altındaki kayıt defteri girişlerinde gördüğünüz GUID (ler) ile karıştırıldığı konusunda haklısınız. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Search\CrawlScopeManager\Windows\SystemIndex\*, ve bu dosya GUID (ler) in sağlayıcısı olmalıdır.

Birimler klonlandığından, bu belirli dosya, diğer dosyalar gibi her biri arasında aynıdır. Ve hacimler monte edildiğinde, tıpkı seri dizileri gibi, "güncellenmez" (yani çatışmaları önlemek için yenilenir):

enter image description here

Bununla birlikte, görünüşe göre bu dosyanın silinmesi güvenlidir ve birim tekrar monte edildikten sonra yeni bir tane üretilecektir; TÜM kopyalanan bir GUID'e sahip olan hacimlerin benzersiz GUID'lerle yeniden bağlanması durumunda sorun çözülecektir (mevcut sistem hacmini içeriyorsa yeniden başlatma gerekebilir):

enter image description here

enter image description here

Ne yazık ki, Windows altında silmek için uygun / güvenli bir yol olup olmadığından emin değilim:

enter image description here


Etkileyici. Bunu nasıl anladın?
Jon

1
NTFS (meta veri, meta dosya ...) ile ilgili bilgileri sınama ve çevirme yaptım ve gerçekten öyle bir şey bulamadım. Sonra da FAT32 ile test etmem ve olayların farklı davranıp davranmadığını görmem gerektiğini düşündüm. Bu yüzden bunun muhtemelen her iki tür dosya sisteminde de bulunabilecek bazı gizli sistem dosyalarıyla ilgili olduğunu düşünüyorum.
Tom Yan

Tamam, bilgisayarıma geri döndüğümde, cevabınızı kabul edebildiğimden emin olacağım. Öyleyse, FAT32'nin NTFS'nin "birim benzersiz tanımlayıcısı" eşdeğeri yok mu? Yine de bir tasarım hatası gibi görünüyor - yani oradayken NTFS özelliğini kullanmalı, aksi takdirde gizli bir sistem dosyası GUID'sine geri dönemedi. Btw silmek, mülkiyet alarak ve güvenlik izinlerini değiştirerek mümkün görünüyor.
Jon

volume unique id ( mountvol X: /L ) dosya sistemi ile ilgisi yoktur, sadece bölüm (tablo). GPT disk için, Windows unique partition GUID gibi volume unique id. MBR disk için, disk tanımlayıcısını kullanır ( uniqueid içinde diskpart ) ve bölümün başlangıç ​​konumunu oluşturmak üzere volume unique id. Hem FAT32 hem de NTFS var volume serial; bu sadece NTFS'den biridir ve teknik olarak daha uzundur ( fsutil fsinfo ntfsinfo X:, ancak kontrol ederseniz dir X: NTFS serisinin sadece bir kısmı, muhtemelen daha kısa FAT32 serisiyle uyumluluk için gösterilmiştir).
Tom Yan

Her nasılsa, Microsoft, dizini oluşturucu için herhangi bir seri / kimlik kullanmamayı tercih eder, ancak rasgele bir tane daha üretir ve birim monte edildiğinde gizli bir sistem dosyasında (zaten mevcut değilse) saklar. Yine de bir tasarım kusuru olarak adlandırılıp adlandırılmadığından emin değilim. Sadece Microsoft yapılacak ortodoks bir şeyi "klonlamayı" düşünmüyor. (Ancak, en azından Windows, bölüm tablosundaki bu GUID'leri sizin için yeniden oluşturur.)
Tom Yan
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.