If you didn’t already know, you can access any file stored in SharePoint (2007 or 2010) as though it was a folder on your system. The secret is to make it a network drive. You can do this a couple of ways. The easiest way is to open the library in Explorer. In SharePoint 2010, you’ll find this option in the list ribbon, on the library tab. Depending on the width of your screen, this may only appear as an icon.
Once you click on it, you’ll see your files in a regular Explorer Window. Depending on your Explorer settings, you may also see a folder named forms. Do not touch that folder, and do not attempt to add a new folder named forms…. you will break your library. That folder contains the files necessary to properly render the library in a browser. Just pretend that it isn’t there.
Once you do this, your system will “remember” this library and you will be able to to navigate directly to it through the Network node of your Explorer window.
You can also add this link directly, by right clicking on your computer in the explorer view, selecting Add Network Location, and entering the URL of your library (or server) there.
This is all possible due to the magic of WebDAV (Web Distributed Authoring and Versioning). It’s a protocol for transferring binary files over http and is what is behind the concept of web folders. It’s an interesting acronym because the none of the implementations of the protocol that I’ve ever seen (it’s been around for about 12 years now) have anything at all to do with versioning,but I digress.
For any of this to work,the WebClient service must be running on the client machine, and if you’re using a server operating system, the Desktop Experience must be installed.
This works great for most cases. If you’re opening the files in Word, Excel etc, those applications understand that they’re opening content in SharePoint and they’ll happily write directly back to it……in most cases. The problem is that what is actually happening is that the file is being brought down locally, and synchronized back to the server, or written back directly by the application.
We recently came across a case where we were using an Excel spreadsheet that was stored in SharePoint as a data source in an SSIS (SQL Server Integration Services) process. Everything worked just fine, but the package was not picking up any changes. As it turns out, when we told SSIS the source path of the Excel file, we used the WebDAV address, which was http://server/site/library/filename.xlsx. What then happened was that SSIS pulled down a copy of the file to a temp folder, and then used that file from then on. Not so good.
The fix for this was to use a UNC path (the standard machinenamesharedfolder style). What is the UNC path for a WebDAV folder? It’s not well advertised, but it’s
Server URL can be a FQDN or a machine name, depending on your configuration, and the site structure begins after DavWWWRoot. The DavWWWRoot is a constant that tells Explorer that it is dealing with WebDav, and must always be present.
It’s probably a good idea to use the UNC path whenever you need to programmatically access files stored on SharePoint.