wssql retourne toujours zéro lignes

Question

J'utilise le service windows search 4.0 (wssql) pour trouver des fichiers, ça marche bien sur mon ordinateur mais sur notre serveur qui a deux lecteurs C: et D: retourne toujours 0 lignes lors de la recherche D:

Aussi je ne sais pas si c'est lié mais cd d: retourne à c: dans l'invite de commande.

Editer: Ok, il semble qu'il ne renvoie que zéro lignes lorsque je spécifie où scope = 'D:' la même chose se produit dans le lecteur c. En outre, le lecteur n'est pas un lecteur réseau.

Answer 1

Il s'avère que le protocole peut être spécifié et que les résultats diffèrent entre les systèmes lorsqu'il n'est pas spécifié. Ajout de fichier: au chemin produit la sortie correcte.

Answer 2

Vous ne pouvez le faire que si vous indexez les partages, pas les lecteurs réseau mappés, comme MLNY ci-dessus. Les fichiers locaux obtiennent des chemins comme c: \ foo \ bar.txt, mais si vous les partagez et interrogez l'index local comme s'il s'agissait d'un partage distant, les chemins deviennent \ server \ share \ foo \ bar.txt. Les chemins sur les partages indexés via le gestionnaire de protocole UNC/FAT sont naturellement \ server \ share \ dir \ file.txt, pas besoin de convertir quoi que ce soit. Mais les lecteurs réseau mappés ne sont ni l'un ni l'autre, donc leur chemin est z: \ foo \ bar.txt et aucun moyen de convertir automatiquement. Nous n'indexons pas les partages dès la sortie de la boîte pour une raison donnée. Le protocole SMB ne nous permet pas de nous éloigner des autres applications quand ils veulent ouvrir le fichier que nous indexons comme nous le faisons avec le système de fichiers local, donc l'indexeur peut verrouiller vos documents lorsque vous les changez. Les éditeurs comme Microsoft Office n'aiment vraiment pas ça. En outre, les lecteurs NTFS locaux fournissent des journaux de modifications. Par conséquent, nous n'avons pas besoin de tout réexaminer à chaque démarrage pour nous assurer que rien n'a changé lorsque nous ne cherchions pas. Les FAT et les partages SMB ne disposent pas d'un tel journal. L'indexeur va donc tout réexplorer à chaque démarrage, ce qui provoque une surcharge du trafic réseau. S'il y a beaucoup de clients, les lancer en même temps (lundi matin?) Provoque une attaque DDoS sur le serveur de fichiers. Nous préférons que vous indexiez les fichiers tels qu'ils sont et les interrogent à distance.