Click here to Skip to main content
15,888,527 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
Hi,
I've been tinkering with the WPF Folder Browser to enhance it by introducing a couple of new features. During this work I ran into a curious issue with DirectoryInfo.Attributes that failed to respond quickly for a certain folder on our network.

What I do in short is checking all folders if they are hidden - in which case I don't attempt to load them. One folder took about 15 minutes to respond. I am not particularly interested in this folder, more interested in getting a response back to the user. What should my approach to this problem be?
The code listed below with a link to the article:

C#
private void LoadFolders()
{
    try
    {
        if (Folders.Count > 0)
            return;
        string[] dirs = null;
        string fullPath = Path.Combine(FolderPath, FolderName);
        var bDrive = FolderName.Contains(':');
        if (FolderName.Contains(':'))//This is a drive
        {
            fullPath = string.Concat(FolderName, @"\");
        }
        else
        {
            fullPath = FolderPath;
        }
        dirs = Directory.GetDirectories(fullPath);
        Folders.Clear();
        foreach (string dir in dirs)
        {
            try
            {
                DirectoryInfo di = new DirectoryInfo(dir);
                // create the sub-structure only if this is not a hidden directory
                //TODO hack SORT OUT THIS WAITING BUSINESS - For some reason this path doesn't answer di.Attributes for 15 minutes?!?
                if (dir.StartsWith("P:\\USAUS")) continue;
                //WORK AROUND Line below - (when a full path is pasted into the text box - only expand the actual path (or as much of it as possible)
                if (!(Root.SelectedFolder.StartsWith(dir) || System.IO.Path.GetDirectoryName(dir) == (Root.SelectedFolder + (bDrive ? @"\" : "")))) continue;
                if ((di.Attributes & FileAttributes.Hidden) != FileAttributes.Hidden)
                {
                    Folders.Add(new FolderViewModel
                                    {
                                        Root = this.Root,
                                        FolderName = Path.GetFileName(dir),
                                        FolderPath = Path.GetFullPath(dir),
                                        FolderIcon = "Images\\FolderClosed.png"
                                    });
                }
            }
            catch (UnauthorizedAccessException ae)
            {
                Console.WriteLine(ae.Message);
            }
            catch (Exception e)
            {
                Console.WriteLine(e.Message);
            }
        }
        if (FolderName.Contains(":"))
            FolderIcon = "Images\\HardDisk.ico";
    }
    catch (UnauthorizedAccessException ae)
    {
        Console.WriteLine(ae.Message);
    }
    catch (IOException ie)
    {
        Console.WriteLine(ie.Message);
    }
}




WPF Folder Browser[^]

Thanks in advance.
Erik
Posted
Updated 29-Apr-12 23:57pm
v2
Comments
SASS_Shooter 30-Apr-12 16:27pm    
Is this directory on the network? I've found frequently when a DIR directive takes so long it is on a network drive. If so you may then need to run a sniffer to see what kind of communications goes on between your machine and the server that the directory is on.
Erik Rude 30-Apr-12 18:30pm    
Yes, it is a network drive - it is quite possibly on the other side of the Atlantic, but what I really need to properly understand is how I make the process of asking for the information react in a way that doesn't mean I have to wait for 15 minutes for it to fail. The program will not only run on networks that I know, but also unknown to me networks.

1 solution

The first thing I would suggest, then, is to get the sniffer trace run. It could be something as simple as challenge/response timing out, in which case you work to get the timing increased so you get the response back in enough time.

It may also show you if you are getting fragmented packets or other network related issues that can be fixed with with routers or infrastructure.

Sometimes you have no choice in your environment and it is a matter of what you can do in the background to fix it. I sat in on a huge discussion at Tech Ed one year on the subject of satellite communication to a branch in South America. That was a bugger because the transmit up and back add 1 second each way!!

You may be able to get enough issues resolved via the sniffer trace that you can then establish a minimum in your requirements such as challenge-response timeout, packet size, etc. Unfortunately, DirectoryInfo does not incorporate (that I know of) any kind of timeout settings as it relies on the stack for that.
 
Share this answer
 
Comments
Erik Rude 2-May-12 9:48am    
Thanks for the time to get me an answer. I wonder what they do in explorer to get round this issue. I can see how this can be difficult to solve.
SASS_Shooter 2-May-12 10:58am    
Erik, if you have a good network guy that can work with you there may be a quick answer to your question. In 95 I had a horrible time with my internet provider. Working with Microsoft at the time they signed in as me and came back to tell me the provider was not following RFC. I pointed out the issue to them and they acknowledged the failure but blamed MS for it!!!! I dropped them and went to a new provider and had a fast connect (for what was available at the time).

Once you can see the packets it will be much easier to see exactly what is happening and then you can find your answer.
Erik Rude 4-May-12 9:54am    
Hi Sass, Thanks, I've reported the issue to our IT guys and they're looking at it. I think to solve the problem of not having to hang for extended hours waiting for a dialog box to populate I probably have to create my own wrapper to DirInfo, where I create individual processes for each call and have a timeout that may kill the process in case of too long answer times. This will clearly have to be another day as I don't have time for this right now. Cheers for your help.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900