5

I have a Windows 2012 R2 server running as a VM (on top of KVM/Libvirt). It has an extra "internal" disk defined as F:

If I snapshot the Linux-based host's logical volume representing F: and mount it on the host I get many files tagged as being an unsupported reparse point.

What I want to do is to backup the filesystem from the host, which is why I've started from here.


Here is an example from the host's perspective

lvcreate --name shares-snap --size 10G --snapshot /dev/crypt_md3/shares
mount -o ro,offset=$((129*1024*1024)) /dev/crypt_md3/shares-snap /mnt/dsk
ls -l /mnt/dsk/mfc70.dll
lrwxrwxrwx 1 root root 26 Jan  5  2002 /mnt/dsk/mfc70.dll -> unsupported reparse point

Within the Windows guest, the file properties dialog shows its size to be 952KB but with the size on the disk as 0 bytes. This is classic for a reparse point. The advanced attributes are APL, with the L confirming that the file is indeed a reparse point.

Copying the file removes the P and L attributes from the copy.

Searching around lead me to How do you find the target of a symlink created with mklink and its accepted answer. I've downloaded both junction 1.06 and NTFSLinksView.

Running junction gets me nothing useful:

F:\> c:\local\bin\junction mfc70.dll

Junction v1.06 - Windows junction creator and reparse point viewer
Copyright (C) 2000-2010 Mark Russinovich
Sysinternals - www.sysinternals.com

F:\mfc70.dll: UNKNOWN MICROSOFT REPARSE POINT

Running dir /L gets me nothing useful either:

F:\>dir /L mfc70.dll
 Volume in drive F is Folder shares
 Volume Serial Number is B600-69DE

 Directory of F:\

05/01/2002  04:48           974,848 mfc70.dll
               1 File(s)        974,848 bytes
               0 Dir(s)  233,785,053,184 bytes free

Running dir /A:L does include the file, so it's definitely a reparse point of some sort.

NTFSLinksView simply doesn't list the file.


After all this background information, the question is really rather simple:

  1. How do I find out details of the reparse point?
  2. What do I tell ntfs-3g on the host to remap the junction points so they resolve?
roaima
  • 1,567
  • 13
  • 26
  • Do you understand the difference between a junction and a symbolic link? – Greg Askew Dec 10 '15 at 16:17
  • @GregAskew I understand symlinks in the UNIX/Linux world. Inferring from your question, I need to go and (re)read the differences in the Windows world. If this is actually a symlink then the same question stands, but clearly my methodology would be suspect. – roaima Dec 10 '15 at 16:19
  • http://stackoverflow.com/questions/9042542/what-is-the-difference-between-ntfs-junction-points-and-symbolic-links – Greg Askew Dec 10 '15 at 16:20
  • @GregAskew in the light of that reference would it make more sense to remove the word "junction" from my question, throughout? – roaima Dec 10 '15 at 16:21
  • You should also remote the part about using the SysInternals junction utility. Whatever you are doing for a link should be doable with mklink.exe. Also, you're mixing unix and Windows commands to the point where the question is almost incoherent. In Windows, to see the target of a link all you need is the `dir /l` command. – Greg Askew Dec 10 '15 at 16:24
  • @GregAskew `mklink.exe` doesn't show me anything. It lets me create links of various types but I cannot use it to find out where this link resolves. – roaima Dec 10 '15 at 16:36

1 Answers1

5

These are probably de-duped files. They are implemented with junctions on disk and the file system driver handles reassembly. I doubt you will find a Linux tool that can deal with them. And other Windows utilities for junctions won't understand them because they were designed for regular junctions, not de-dupe junctions.

longneck
  • 22,793
  • 4
  • 50
  • 84
  • Have I got any way to determine the file on which such a deduplicated file is based? – roaima Dec 10 '15 at 17:15
  • De-duplication happens at the block level. There are no utilities that I am aware of to peek under the covers. – longneck Dec 10 '15 at 17:54
  • 1
    If dedup happens at the block level why should I see this file as a reparse point rather than a file? To me this suggests there's something going on at the file level. – roaima Dec 10 '15 at 22:23
  • 1
    You're using outdated tools and a UI that is purposely designed to hide the implementation details of de-dupe. Don't trust your "senses". Read Microsoft's documentation on de-dupe.But to answer your question directly, it's because the reparse point is a flag to the NTFS driver to look elsewhere, and the target is the de-dupe table. Since the de-dupe table isn't a file, the UI (Explorer) and tools don't know what to do with it. – longneck Dec 10 '15 at 22:56
  • See http://blogs.technet.com/b/filecab/archive/2012/05/21/introduction-to-data-deduplication-in-windows-server-2012.aspx – longneck Dec 11 '15 at 02:51