Maintaining the service we sometimes lose sight of how people interact with Sharepoint, and we know that some users really don’t like Sharepoint 2013’s user interface that much – and prefer to use a combination of WebDAV or “View in Explorer” to manage all their documents and interactions with Sharepoint.
Which is fine…until you start falling into the bad habit of assuming that Sharepoint is “just another file system” and that handy explorer / folder view of your document library behaves exactly like the explorer view of your hard drive or network attached storage.
It doesn’t – and in this particular curious case, a task was raised with us claiming that “Sharepoint ate my content”.
The first place we always look is the second stage recycle bin. If anything was deleted from Sharepoint it would show up in there, regardless of the method used to despatch those documents. Sure enough, the described documents were sitting in the second stage recycle bin – the document library they’d allegedly been scoffed from was indeed empty, no matter how I looked at it.
I sent the task back, recommending that the user restored the items from the second stage bin – and expected to hear no more about it. Strangely enough the ticket “boomeranged” pretty quickly and came back to me, with the user reporting an odd message that on attempting to restore the content, Sharepoint could not comply because “The content is already there”
Curiouser and curioser.
I then assumed that they’d done something like deleted the documents (in explorer view) and the documents were sitting in their local recycle bin on their machine, stuck in limbo between Sharepoint still retaining the database entries for those documents (more on that later) and the documents not actually being visible to anyone, even someone with the highest level of access to Sharepoint.
Of course, at the time had I known a bit more about what the user had done (as with most service desk requests to our service, the user usually won’t tell you how they use the service, you’re supposed to know that automatically) I could’ve guessed what happened.
You see, that business about Sharepoint not being a file system is very true – and it’s also misleading that the Explorer View (or WebDAV view) behaves for the most part like a file system until you start trying to do distinctly non-Sharepoint things with it. Like moving content around.
The user had (though the details are still scarce) obviously set up a couple of explorer views, and started dragging content around willy-nilly within their document library’s folder structure. So as far as Sharepoint was concerned, those documents were being COPIED not moved. The user obviously then deleted the original items from their original location (which is why they showed up in the recycle bin) but of course had also fallen foul of their library’s check in / check out settings. Essentially the documents were stuck in a ‘checked out’ form, and so there were actually two copies – ones that had been deleted but still existed on Sharepoint – hence the error message when trying to restore, and ones that had just been dragged and dropped (without paying attention to the check in requirements) to somewhere else within Sharepoint. So when I looked in the document library I couldn’t see anything – because the documents were actually sitting in the root folder for that library in a checked out state. I was looking in the wrong place, and the user was too!
One quick visit to the library’s settings page and the “Manage Documents Which Have No Checked In Version” menu item revealed the missing documents, sitting there in a checked out state blissfully unaware of the strange chain of events that had just happened. Once the user had taken ownership of the documents, they were back where they should have been and the problem was resolved.
Phew! This all sounds more complicated than it actually is but it did throw me a curve ball I wasn’t expecting, and it also shows that Sharepoint is actually very good at “not eating your homework” even when you push it in directions it isn’t expecting to go in.
Thank goodness that one didn’t involve a site collection restore (as they’re majorly painful to do and take ages).