3

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?
  • 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
  • @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
4

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.

| improve this answer | |
  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.