“Previous Versions” and Shadow Copies with Very Long Paths

I was working on a server the other day and needed to recover files from a previous version of a folder through Previous Versions.  (A backup was not available on the particular folder for reasons I won’t get into here.)  I ran into a problem that I couldn’t really find documented very well anywhere and thought I would document it for others.

I first made sure there was a previous version available:

In fact, this was through a shadow copy, which will turn out to be very important:

So, we have the previous state of the folder, it’s in a local snapshot, so I could get it back, right?  Let’s see what happened.  I clicked Open on the Previous Versions tab, then navigated through Explorer to the folder that has the file I want to get.  It turns out this file is nested a few levels deep in a set of long folder names, and has a long filename as its exposed filename:

\\localhost\C$\Users\Administrator\Desktop\Somewhat Long Folder Name\Another really long folder name for a good reason that you do not know\Yet another long nested folder name believe it or not (‎Today, ‎January ‎26, ‎2012, ‏‎12 minutes ago)\Long file name here as well that will be a problem for us soon.txt

Why is the long name a problem?  Well, when I tried to copy the folder out of the shadow copy, I got this 100% correct yet not helpful error:

Or, in text form:

The source file name(s) are larger than is supported by the file system. Try moving to a location which has a shorter path name, or try renaming to shorter name(s) before attempting this operation.

Questionable grammar aside, the error’s suggestions, which relate to changing the source, are useless, because shadow copies are read-only.  So now what?

Well, the reason the path is too long is because with the shadow copy overhead added to the path, the filename has a length longer than MAX_PATH, or 260 characters.  I suspect Explorer still cares due to backwards compatibility, which is why the Unicode 32K path length doesn’t come into play, but that’s just a guess.  Anyway, this still leaves the problem of getting a shorter filename.

The answer is to surface or expose the shadow copy as a drive letter.  There are multiple ways to go about this.  The first one that I thought of – to use the diskshadow command that is new in Windows Server 2008 – didn’t work as I expected.  Let’s see what happened, then explain a solution.

First, we find the exact name of the shadow copy.  I listed them to a file (I used diskshadow for consistency, although vssadmin would also let me do that piece), then searched the file in Notepad:

C:\Users\Administrator\Desktop>diskshadow /l shadows.txt
Microsoft DiskShadow version 1.0
Copyright (C) 2007 Microsoft Corporation
On computer:  DEMOSERVER,  1/26/2012 11:20:09 AM

DISKSHADOW> list shadows all

… shadow listing here …

Number of shadow copies listed: 196

DISKSHADOW> exit

C:\Users\Administrator\Desktop>notepad shadows.txt

In this case I wanted the 10:41:53 AM snapshot on January 26, 2012 for the C: drive, which looked like this in the log:

* Shadow copy ID = {1cbf48de-1e49-4ae4-9a24-0c75d3dc4c6d}
– Shadow copy set: {55c21b6c-b34f-4f0c-88df-e03fc952f39e}
– Original count of shadow copies = 1
– Original volume name: \\?\Volume{12cba6d6-7540-11e0-bd41-806e6f6e6963}\ [C:\]
– Creation time: 1/26/2012 10:41:53 AM
– Shadow copy device name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy266
– Originating machine: DEMOSERVER
– Service machine: DEMOSERVER
– Not exposed
– Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5}
– Attributes:  No_Auto_Release Persistent Client_accessible No_Writers Differential

Next, I want to map the path to a shorter location.  I thought I could do this through diskshadow, but it turns out there’s a restriction that prevents this:

DISKSHADOW> expose {1cbf48de-1e49-4ae4-9a24-0c75d3dc4c6d} P:
Client accessible shadow copies cannot be exposed.

The GUID in the expose command is the “Shadow copy ID” given in the listing.  Because the shadow copy is accessible to the client (through Previous Versions), I couldn’t directly map it to a drive.  So now what?

Well, the trick was on a Microsoft blog — using a symbolic link to get to the shadow copy:

C:\Users\Administrator\Desktop>mklink /d c:\s \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy266\
symbolic link created for c:\s \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy266\

The link is from a very short-named local folder to the “Shadow copy device name” given in the listing.  As explained in the blog post, I didn’t forget to add a trailing slash to the mapping (it won’t work if you don’t do that).  Now, I can look at this linked version in Explorer, and copy the data!

Then, I deleted the symbolic link with rmdir c:\s to clean up, and that was that!

I hope this helps should you run in to the same error trying to copy from a previous version.

— Michael C. Bazarewsky