“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


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

20 thoughts on ““Previous Versions” and Shadow Copies with Very Long Paths

  1. This is just what I needed to recover a share after Cryptolocker ransomware encrypted every office file! Thanks very much for posting!


  2. Doesn’t seem to work in Server 2012R2 (or at least mine). I’m able to create the symbolic link and it appears in explorer but when I try to open it or run a dir on it security won’t let me open it. Any ideas?


  3. This has saved me twice now so thank you. Also, just so it’s clear, the error I got when I did not include the trailing slash was “Parameter Incorrect” but this only happened after I tried to open it. It can be a pain because the link is created and shows but when you try to actually use it the error is a little hard to understand. I was warned though so user error….

    This is also a great way compare what has changed between two shadow copies because you can then load them into a program like RoboCopy or (my personal favorite) Beyond Compare from Scooter Software. When we got hit with CryptoLocker we used this to see what files we needed to restore from the previous versions as well as what had changed.


  4. Please would you tell me if this could be used as a method of defence against cryptolocker?

    1) Back up all data to a folder.
    2) Change the folder name and path to a length longer than maxpath
    3) Hope that cryptolocker will not be able to get into the folder to encrypt the data in it.

    Or alternatively might it be possible to add some weird Cyrillic, Japanese, and symbols (Ѥ薔Ю薇Ѫ♥Ѭ♪Ѧ© Ѩ→Ѯ欝ѰѤ薔Ю薇Ѫ♥Ѭ♪Ѧ© Ѩ→Ѯ欝ѰѤ薔Ю薇Ѫ♥Ѭ♪Ѧ© Ѩ→Ѯ欝ѰѤ薔Ю薇Ѫ♥Ѭ♪Ѧ© Ѩ→Ѯ欝Ѱ) to the long path name to make it even more inaccessible?


Leave a Reply to Jamie Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s