HiddenWebDAVFiles - DocumentationSpace - Confluence--GCC Wiki Implementation

	DocumentationSpace	Log In
	HiddenWebDAVFiles

Browse Space

View
Info

Added by Mark Edgar, last edited by Mark Edgar on Jan 08, 2007 (view change)

This issue has helpdesk ticket 537906.

Note that the original reported problem is in copying Visual Basic project directories via the Windows XP WebDAV client. Apparently, the .suo file in a VB project directory is marked with the hidden attribute by Visual Basic. This means that while IIS will report that the file exists in the response to a PROPFIND request on the file's parent directory, it will also report a 404 error in response to a GET request for the file. This, in turn, causes MRXDAV.SYS (the XP WebDAV client) to silently abort the directory copy operation. Whatever files have been successfully copied so far are copied, but any remaining files are not copied.

Listed below are several possible solutions listed in the order of (what I believe to be) the most appealing to least appealing:

Microsoft releases a patch to us which allows IIS to serve hidden static files via its WebDAV-enabled HTTP.

Microsoft fixes MRXDAV.SYS to 1) notify the user of a failure to copy a given file and 2) allow the user to continue to copy the remaining files.

We find a replacement for IIS on files.gccaz.edu which will serve hidden files as well as meet our other requirements (eGCC authentication, secure WebDAV-enabled HTTPS, secure FTP, ability to serve UNC paths under the authorization of the authenticating user; see RemoteFileAccessService for more information).

We instruct our XP users to use another method of remote file access, at least for troublesome files. Note that the IIS FTP service (currently enabled) will, in fact, serve hidden files. The IIS WebDAV-enabled HTTP service will not. So, "this behavior is by design" noted at http://support.microsoft.com/kb/216803/ seems to be applied only selectively. I'd like to apply it optionally.

We instruct our XP users to avoid the built-in WebDAV client and use a third-party WebDAV client instead.

As you can see, training the users is dead last here. I'd rather us jump through hoops than our users.

Comments (Hide)

I sent our concerns to Microsoft this morning and we'll see if they can provide us with a workaround or any other solutions.

Cyril

Posted by Cyril Azoulay at Jan 08, 2007 13:04 | Permalink

First answer from Microsoft:

Cyril,

Thanks for your email. I could not find any specific resolution it may be best to open a support incident to find if it is "by design" or if there is a bug in this. (I am guessing that it a design issue with IIS and [WebDAV]).

Bruce, what are your thoughts on this?

I found this following KB article that may be helpful, but it is a long shot: http://support.microsoft.com/kb/287402/en-us

specifically this portion:

6.	On Windows 2000 and Windows XP, use the Web Folders Repair utility (webfldrs.msi):	1.	Start Windows Explorer.
2.	On the main drive, navigate to WINNT\System32.
3.	On the Tools menu, click Folder Options.
4.	In the Folders Options dialog box, click the View tab.
5.	Click to select the Show Hidden Files check box, and then click OK.
6.	Locate the webfldrs.msi file, and then double-click it.
7.	Click Reinstall.
8.	Restart the computer after installation has completed

Thanks,

DarenS

Posted by Cyril Azoulay at Jan 18, 2007 15:28 | Permalink

Second answer from Microsoft:

Cyril,

I have gone through and checked the database for any changes in latter builds "Post Xp2" of MRXDAV.SYS that have corrected this issue and it appears we have not as of this point changed this behavior.

You are correct, the behavior is by design as noted in the KB you listed 216803, but you are able to also copy with IIS and FTP this certainly seems to be contradictory.

I am in communication with the IIS group to see what the best course of action they recommend would be at this point.

Is there a set reason you want to use IIS to do the copy, or would you be willing to explore other copy methods.

Bruce

Posted by Cyril Azoulay at Jan 23, 2007 16:49 | Permalink

I wrote the following email to forward to Bruce at Microsoft support:

Bruce at Microsoft writes:
> Cyril,
>
> I have gone through and checked the database for any changes in
> latter builds "Post Xp2" of MRXDAV.SYS that have corrected this issue
> and it appears we have not as of this point changed this behavior.

So, there are two issues here. This first one, the MRXDAV
aborts-copy-operations-on-404 issue, is annoying and very confusing to
the users, but it isn't really the big problem for us. We'd like to be
notified when it's fixed, but we can't update our users' home computers
anyway.

> You are correct, the behavior is by design as noted in the KB you
> listed 216803, but you are able to also copy with IIS and FTP this
> certainly seems to be contradictory.

Yes, IIS-FTP serving hidden content is contradictory. But in my opinion
it is even more contradictory that IIS-HTTP will list hidden content (in
PROPFIND requests), but not serve it.

> I am in communication with the IIS group to see what the best course
> of action they recommend would be at this point.

The best solution would be a new switch which tells IIS to serve all
content regardless of any Hidden attribute. Of course the default
setting should remain as NOT serving hidden content. I don't personally
care if this switch is buried in the registry instead of being made
available via the "Internet Information Services (IIS) Manager" user
interface.

> Is there a set reason you want to use IIS to do the copy, or would
> you be willing to explore other copy methods.

Our goal is to provide our users with access to the "home" and "shared"
DFS roots from off-campus. [WebDAV] seems the best way to do this. While
we do also provide FTP access to these spaces (also with IIS), we would
really prefer not to use FTP at all or to switch to secure FTP (which
IIS doesn't support).

The big issue is as follows. Our users (really, our users'
applications) create hidden files. Our users need to access these
hidden files via [WebDAV].

The prime example right now is Visual Studio. A student submits her
homework assignment by copying her project directory to the shared
network space, making it available to her instructor. Since Visual
Studio makes the .suo file hidden, and the project cannot be opened
without this file, the instructor cannot use [WebDAV] to either open or
copy the student's project for grading.

Another example is Microsoft Word which creates hidden recovery files.
So far only our Mac Word users seem to be affected by this.

We expect to run into similar issues with other applications.

We can certainly explore other copy methods, for example: FTP, SCP,
remote desktop, web-based file management, even sneaker-net. We'd
actually like to provide as many options to our users as we can
reasonably support. However, the expectation is that all of these
access methods should be equivalent to each other; they should all
provide the same view of the user's files which the user sees when
accessing the content on-site via SMB.

If IIS-HTTP cannot be persuaded to serve hidden content, then the only
option we have is to use a [WebDAV]-capable server other than IIS.

-Mark

P.S.

A possible solution which just sprung to mind: an IIS filter which
serves hidden files in spite of the default behavior. This would of
course be a hack on top of an unwanted feature. It's truly ugly, and
I'll of course start writing it immediately.

Posted by Mark Edgar at Jan 26, 2007 11:20 | Permalink

I wrote the program mentioned in the above PostScript.

Posted by Mark Edgar at Jan 26, 2007 11:21 | Permalink

Update!!!

Hello Cyril,

This has taken longer than the normal case would. Maricopa Community College has a Premier contract but access is limited to Linda Hannigan's group currently so we have not been able to follow the usual open a case with the appropriate support team for assistance model.

I have been engaging engineers with the IIS team for assistance with this matter but not through the normal channel of an open PSS case.

I have a resource who is willing to look into this matter for us and they have requested as a first step that we gather a network capture of the behavior. Are you familiar with the Microsoft Network Monitor?

http://support.microsoft.com/kb/294818

http://support.microsoft.com/kb/243270/en-us

http://support.microsoft.com/kb/148942/en-us

Can we install Network Monitor and take a trace of the failure occurring from the client and server end of the traffic and then send that data to me for the IIS engineer to examine. They would like to confirm what is happening on the wire before proceeding.

Thank you

Bruce

Posted by Cyril Azoulay at Mar 20, 2007 12:05 | Permalink