일부 파일을 찾기 위해 windows search 4.0 서비스 (wssql)를 사용하고 있지만 내 컴퓨터에서는 잘 작동하지만 두 개의 드라이브가있는 서버에서는 C : 및 D : 검색시 항상 0 행을 반환합니다. D :wssql은 항상 0 행을 반환합니다.
또한 관련이 있는지 확실하지 않지만 cd d : 명령 프롬프트에서 c :로 돌아갑니다.
편집 : 좋아요, 어디로 범위 = 'D :'를 지정할 때 제로 행을 반환하는 것으로 나타납니다 동일한 문제가 c 드라이브에서 발생합니다. 또한 드라이브가 네트워크 드라이브가 아닙니다.
지정되지 않은 경우 프로토콜을 지정하고 시스템간에 결과가 다를 수 있습니다. 경로에 파일 추가 : 올바른 출력을 생성했습니다.
위의 MLNY와 마찬가지로 매핑 된 네트워크 드라이브가 아닌 공유에 대한 색인을 생성하는 경우에만이를 수행 할 수 있습니다. 로컬 파일은 c : \ foo \ bar.txt와 같은 경로를 가지지 만 공유하고 로컬 인덱스를 원격 공유처럼 쿼리하면 경로는 \ server \ share \ foo \ bar.txt가됩니다. UNC/FAT 프로토콜 처리기를 통해 인덱싱 된 공유 경로는 자연스럽게 \ server \ share \ dir \ file.txt이므로 아무 것도 변환 할 필요가 없습니다. 그러나 매핑 된 네트워크 드라이브는 둘 다 아니므로 경로는 z : \ foo \ bar.txt이며 자동으로 변환 할 방법이 없습니다.
이유 때문에 입력란에 색인을 생성하지 않습니다. SMB 프로토콜을 사용하면 로컬 파일 시스템에서와 같이 색인을 생성하는 파일을 열 때 다른 응용 프로그램의 방해를받지 않기 때문에 색인을 변경하면 색인자가 잠금 될 수 있습니다. Microsoft Office와 같은 편집자는 그 점을 정말로 좋아하지 않습니다. 또한 로컬 NTFS 드라이브는 변경 저널을 제공하기 때문에 모든 시동시 모든 것을 다시 크롤링 할 필요가 없으므로 찾고 있지 않을 때 아무 것도 변경되지 않습니다. FAT 및 SMB 공유에는 이러한 저널이 없으므로 인덱서가 시작할 때마다 모든 항목을 다시 크롤링하여 많은 네트워크 트래픽을 발생시킵니다. 많은 클라이언트가있는 경우 동시에 시작 (월요일 아침?)하면 파일 서버에 DDoS 공격이 발생합니다. 오히려 파일을 색인화하고 원격으로 조회 할 수 있습니다.