VSS paths unable to be used with wimlib-imagex

[chrislong2]

On Windows, I know there's the --snapshot option that allows wimlib to take a snapshot and process and that works.
However, there are situations where someone (i.e. me) wants to handle the snapshot separately (controlling what filters are used for the snapshot etc or in a batch process where a persistent snapshot could be used to avoid wimlib making a new snapshot at each run etc) and then just pass wimlib-imagex the correct VSS path. But trying to use a path like

"\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\MyFolder"

just gets you an error code 47 (failed to open file) and where it says it is scanning "\\MyFolder".

So even though wimlib-imagex can internally work with such paths because it has to for working with its own snapshot, it won't accept such paths on the command-line.

[Skyblue]

Hello,

You would like to use the mklink tool to mount the volume shadow copies :

Code: Select all

mklink /D <drive>:\Folder_recovery_path\ \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy#\

https://myitengineer.com/dr-recover-fil ... ile-level/

[chrislong2]

Thanks! Although I do think ideally wimlib-imagex should be able to handle such paths directly (other tools like 7-zip cmdline version can), this is a reasonable workaround. Appreciate the suggestion.

[chrislong2]

Unfortunately, I discovered that while this workaround does work for specific folders under a snapshot that's been mounted to a directory junction or symlink, it will not work if the VSS snapshot taken was for a full drive and you are wanting to compress everything in the snapshot (not a subfolder). Wimlib will error with exit code 40 ("expected a directory") because when you try to reference the symlink or junction itself, it will claim it is not a directory (even though it IS technically a directory too in addition to being a junction point or symlink). Adding or not adding the trailing slash makes no difference. So the creating of a symlink or junction appears to be a half-workaround, but there still is no way that I have found to make wimlib use a VSS path itself as the source. Any other thoughts?

[chrislong2]

I was able to workaround by instead mounting the volumeshadowcopy as a drive and then using that with wimlib. However, this can bring its own set of issues as it typically then is subject to autorun and may launch Explorer as soon as the mount occurs unless you set various registry entries to disable etc, so this is not an overall great solution. It really would just be much better if wimlib-imagex accepted such paths on the cmdline since we know it can internally use the paths fine. But at least it is possible to workaround in some, albeit clunky, fashion.

[synchronicity]

Hi,

I tested this and paths to the root of the volume do work:

Code: Select all

wimcapture \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\ test.wim

However paths to subdirectories do not work:

Code: Select all

wimcapture \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\Users test.wim
[ERROR] Can't open "\\Users" (status=c0000039): Object Path Component was not a directory object
ERROR: Exiting with error code 47:
       Failed to open a file.

The problem is that Windows has actually corrupted the path to just "\\Users" before the wimlib-imagex executable even started running. This happens with both cmd.exe and Powershell.

I do not know why this is, but it does not seem like something I can solve as it seems to be a Windows problem.

[chrislong2]

Thanks - I must not have actually tried only to the root when I saw that the subdirs didn't work. That at least means that it's workable for root and can be worked around pretty easy by creating a temporary symlink or junction if you want to specify subfolders under the VSS path. I do wonder why Windows does that. It doesn't do that with 7-zip's 7za.exe cmdline tool which is able to correctly see subdir VSS paths fine.