Oddball drive mapping under windows 2000/NT

[Underflow]

Using a Win2000 client and WinNT file server, I've encountered a strange behavior of the List Directory function. When the List Directory is handed a shortcut (.lnk), it attempts to resolve the destination of the shortcut, rather than treating it as a file. This is fairly well documented. The problem that I'm having is that when it does this, a new drive mapping appears on my network listing showing the destination of the shortcut as a new drive (the K:\, M:\, or N:\ drives, for instance). Given a recursive listing of .lnk files (especially with .lnk files that refer to their own directories), the available mapping letters are used up rather quickly. Has anyone else ever experienced this? And is there a fix for it other t
han simply avoiding .lnk files?

[mikeporter]

I haven't ever run into that particular feature, but then I am careful to always filter-out *.lnk files. By the way you also don't want shortcuts in any of the directories in LabVIEW's VI search paths. Very bad things can start happening...

Mike...

[Randy_H]

I would agree with Mike. I was not able to reproduce this issue either. However, I would treat a link to a file as a file and stop there. If the link goes to a directory and I was recursively going down the directory tree, then I would treat the link as a directory.

Randy Hoskin
Applications Engineer
National Instruments
http://www.ni.com/ask

[Underflow]

Thanks for the answers 🙂 I'll make something up to treat the .lnk files more appropriately in the future.

[Fredrick]

I am having the same problem described above. I have mapped a network drive to a NetApp using NTFS file system and assigned the letter K. I am using List Directory function to access text files that contain limits for my test program. I have wired "K:\RF\Limits"
path to the List Directory function and "*.txt" for the pattern. I am using a while loop so that the operator can select the txt file to use before proceeding. All the available drives are mapped as the program loops waiting for the operator's response. I don't have this problem when the program is running on Windows NT. I am only seeing the problem on Windows 2000. I am using Labview 6.02 on both operating systems. I talked to an application engineer at NI but he could not reproduce it.

[icastillejos]

Is this still an issue?

We are seeing significant improvements in performance if we remove our .lnk files from our search directories but I'd like to know why

Can anyone point me to the documentation of this issue?

Thanks a lot in advance

<<-N->>

Message Edited by << - N - >> on 10-31-2008 09:35 AM