Hi Everyone,
We have implemented an installable file system which works quite nicely, but we have a strange problem: Excel cannot open a file if we use UNC. For instance, Start > Run > “excel \server\share\file.xls” causes Excel to display the message:
'\server\share\file.xls' could not be found. Check the spelling of the file name, and verify that the location is correct.
If you are trying to open the file from your list of most recently used file on the File menu, make sure that the file has not been renamed, moved, or deleted.
The extra backslash on the end of the file name in the message isn’t a typo, Excel really does put it there. Perhaps that means something.
If we now map a drive to the share then Start > Run > “excel Z:\file.xls” causes Excel to open the file correctly.
No other application that we have tried has been unable to open a file using UNC - we tried many, including Notepad and Word.
In one particular instance, we were trying to open a file of size 222208 bytes. The reads we saw were the following:
IRP_MJ_READ
ByteOffset = 0 and Length = 32768
We read 32768 and returned success.
IRP_MJ_READ
ByteOffset = 192512 and Length = 32768
We read 29696 and returned success.
So Excel read the first 32768 bytes then jumped to near the end of the file and tried to read beyond it. After this we don’t get any more reads.
We are using Excel 2003 on Windows XP service pack 3. Does anyone have any idea what might be causing this problem?
Cheers, Peter
The difference between these two paths is the means by which the name is
resolved.
In the UNC path case, the name is presented to MUP and it then does name
queries to your FSD. In the connection method, the name is presented
directly to your FSD. Thus, my first question would be “what name is
being presented to your FSD at the IOCTL_REDIR_QUERY_PATH operation, and
how do you respond to that query?”
You might find it insightful to use irp tracker to watch the flow of
operations from Excel to MUP to your FSD as well, particularly if you
can compare it to how CIFS handles this same name. My best guess is
that there is some specific case for which you return an error code that
makes Excel unhappy. That often accounts for cases in which an
application fails but numerous other applications succeed - the working
applications look for any error, and the failing application looks for a
specific error.
Of course, there’s no guarantee that this is the reason for the problem
in this case, but the key difference here is going to be how you handle
the name interrogation.
It is also possible that this is related to your network provider - it
might be the case that Excel is interrogating it and obtaining back a
response it does not expect. Again, there is no invocation of the NP
through the direct connection case. This last suggestion is more
speculative, since I’m not sure precisely how Excel is attempting to
resolve the name.
These application specific failures are maddening, but really do often
come down to an application being displeased with some information you
are returning - it could be the status code or even the information
value. Sometimes it is an attribute bit that you returned at some
point. These issues are usually quite painful to track down since the
application really is a black box and has been programmed to expect very
specific behavior (and that’s why I suggest looking at what CIFS returns
- that’s the expected behavior.)
Good luck. These are never fun.
Tony
OSR
Thanks for the suggestions Tony. I’d never heard of IrpTracker before - I think it’s going to help a lot.
In response to Tony’s first question, we receive two IOCTL_REDIR_QUERY_PATHs.
For the first, the name presented is ‘\server$IPC’ - we return STATUS_BAD_NETWORK_PATH.
For the second, the name presented is ‘\server\share\file.xls’ - we return STATUS_SUCCESS and set LengthAccepted so that ‘\server\share’ is accepted.