This is not a complete solution, but still helpful.
I researched this for one or more hours in the past (more than two months ago) and didn't find much information on this "unsupported reparse point" problem. I had the same problem today, and came to the same conclusion: this looks like a problem with Windows files being weird symlinks or hardlinks. (stat states that it is a symbolic link, and mv states that it is a hard link.)
Helpful: further information can be gained on these files. You might be able to see the target of the symlink by using the mv command.
Below is an example. I shortened "Windows/WinSxS/wow64_microsoft-windows-i..libraries.resources_31bf3856ad364e35_10.0.18362.1_en-us_2cec4e8a6cd56d4c/uihelper.dll.mui" to "Windows/bill.dll.mui" for readability. "Windows/WinSxS/amd64_microsoft-windows-i..libraries.resources_31bf3856ad364e35_10.0.18362.1_en-us_2297a4383874ab51/uihelper.dll.mui" was shortened to "Windows/target.dll.mui" for the same reason.
$ stat '/path/1/Windows/bill.dll.mui'
File: /path/1/Windows/bill.dll.mui -> unsupported reparse point
Size: 25 Blocks: 1 IO Block: 4096 symbolic link
[...]
$ cp '/path/1/Windows/bill.dll.mui' '/dev/null'
cp: cannot stat '/path/1/Windows/bill.dll.mui': No such file or directory
$ mv -n /path/1 /path/dest
[...]
mv: cannot create hard link '/path/dest/1/Windows/bill.dll.mui' to
'/path/dest/1/Windows/target.dll.mui': Operation not permitted
The problem is that "target.dll.mui" is another symlink, and mv didn't help:
$ stat '/path/dest/1/Windows/target.dll.mui'
File: /path/dest/1/Windows/target.dll.mui -> unsupported reparse point
Size: 25 Blocks: 1 IO Block: 4096 symbolic link
[...]
$ cat '/path/dest/1/Windows/target.dll.mui'
cat: /path/dest/1/Windows/target.dll.mui: No such file or directory
The following might help:
- Make a disk image of the partition (use cat or dd to make the ISO file), this saves all of the data. Some of the data might need to be read with Windows, due to this "unsupported reparse point" error.
- Run Windows 95, Windows 98, Windows XP, or Windows 7 in VirtualBox. Run which ever one is oldest and is able to read these problematic files. Mount the ISO file to the virtualized OS and Windows should read them. You can then copy the files out of VirtualBox. If there is some way to make virtualized Windows read files which are not from an ISO file then try that.
- Run Windows Explorer / File Explorer in Wine, perhaps the version of wine that I have, wine-5.0 (Ubuntu 5.0-3ubuntu1), will be able to read them and copy them elsewhere.
Update 1:
Running "wine explorer.exe" did not help.
Use ntfscp2 (ntfs copy 2).
(See https://askubuntu.com/questions/1345356/files-from-windows-with-unsupported-reparse-point-on-ubuntu - about "OneDrive", but still somewhat related to this problem, linked to pagesperso-orange.fr.) I downloaded https://web.archive.org/web/20210712050149if_/https://jp-andre.pagesperso-orange.fr/tools.zip from https://web.archive.org/web/20210709190909/https://jp-andre.pagesperso-orange.fr/advanced-ntfs-3g.html#download
File "tools.zip" has multiple files (explained in file "CONTENTS"):
- "CONTENTS" - plain text file
- not helpful: "ntfs_attr.sh" - mentions "reparse points"
- not helpful: "genusermap.sh"
- maybe helpful: "ntfscp.sh" - mentions "reparse_data"
- was helpful: "ntfscp2.sh" - newer version of ntfscp.sh, less or no bugs, "Recursive copy of a directory tree along with NTFS attributes"
Output of "ls -1 /path/1/Windows" is the same as "ls -1 /path/dest/1/Windows", but some folders/files in /path/dest/1/Windows were missing. Directories synced via ntfscp2.sh:
$ chmod a+x ntfscp2.sh
$ ./ntfscp2.sh "/path/1/Windows" "/path/dest/1/Windows" "/path/dest/setfattr.sh"
$
File "setfattr.sh" is created by ntfscp2.sh when ntfscp2.sh finishes; it might be helpful to run setfattr.sh. setfattr.sh is a "shell script to recreate all the file attributes." So it looks like ntfscp2 is able to correctly copy these problem files. However, once it is copied to the destination, it will still have the "unsupported reparse point" error. When I executed ntfscp2.sh above, I copied from an NTFS hard drive to an NTFS hard drive ("backup volume [need] not be formatted as NTFS"). ntfscp2 might write a second output file: "err". err is a text file with one or more errors. For me, the contents of it was:
/path/1/Windows/WinSxS/x86_wpf-xamlviewerdeploymentmanifest_31bf3856ad364e35_10.0.18362.1_none_ddac88389337a8af/XamlViewer_v0300.xbap: system.ntfs_reparse_data: No such attribute
Proof that the ntfscp2 shell script worked:
- A sorted list (vim :sort) was made from the output of "find . -type f" in the source and destination: the two files were bit-identical.
- A sorted list was made from the output of "find . -type d" in the source and destination: the two files were bit-identical.
- A sorted list was made from the output of "find . -type l" in the source and destination: the two files were bit-identical. (Realize that this compares the list of files, not the contents of them.)
ntfscp2 might not have worked (difference of 101,993 bytes):
$ du -sb /path/1/Windows
62692990548 /path/1/Windows
$ du -sb /path/dest/1/Windows
62692888555 /path/dest/1/Windows
Folder "Windows" contains more than 340,800 files, and I think ntfscp2 modifies extended attributes and maybe other stuff. Therefore this doesn't necessarily mean that ntfscp2 failed; it could just mean that some of the files had their metadata changed.
Without using Windows, one way to access the data is to do some sort of data forensics after researching NTFS. You could unmount /dev/sdc1 then open /dev/sdc1 in a hex editor; then you could look for the files and links, finding the cluster runs or whatever.
