I'm using the windows search 4.0 service (wssql) to find some files, it works fine on my computer but on our server which has two drives C: and D: always returns 0 rows when searching D:
Also i'm not sure if it's related but cd d: goes back to c: in the command prompt.
Edit: Ok it appears that it only returns zero rows when I specify where scope = 'D:' same thing happens in c drive. Also the drive is not a network drive.
You can only do that if you index the shares, not mapped network drives, same as MLNY above. Local files get paths like c:\foo\bar.txt, but if you share them and query the local index as if it was a remote share, the paths become \server\share\foo\bar.txt. Paths on shares indexed via UNC/FAT protocol handler are naturally \server\share\dir\file.txt, no need to convert anything. But mapped network drives are neither, so their path is z:\foo\bar.txt and no way to convert automatically.
we do not index shares out of the box for a reason. SMB protocol does not allow us to get out of the way of other apps when they want to open the file we index like we do with the local file system, so the indexer might be locking your documents as you change them. Editors such as Microsoft Office really don't like that. Also, local NTFS drives provide change journals, so we don't have to recrawl everything on every startup just to make sure that nothing changed when we weren't looking. FATs and SMB shares don't have such a journal, so the indexer will go and recrawl everything on every startup, causing loads of network traffic. If there are many clients, starting them up at the same time (Monday morning?) causes a DDoS attack on the file server. We'd rather that you index files were they are and query them remotely.
Turns out that the protocol can be specified and the results differ between systems when it's not specified. Adding file: to the path produced the correct output.