candera / shadowspawn

A Windows utility that mounts a shadow copy of the disk at a drive letter and then spawns an arbitrary command.
MIT License
188 stars 55 forks source link

robocopy reports error 123 #8

Closed candera closed 13 years ago

candera commented 13 years ago

Background

A user reports here that launching Robocopy via ShadowSpawn results in the error

D:\BAT>D:\Software\ShadowSpawn\W7x64\ShadowSpawn.exe "C:\Users\John\Documents\Outloo~1" q: robocopy q:\ D:\Backup\MEDION\My PSTs" "My.pst" /copyall /np /r:0 /w:0 
ShadowSpawn (c) 2011 Craig Andera. shadowsp...@wangdera.com 
Shadowing C:\Users\John\Documents\Outloo~1 at q: 
Launching command: robocopy q:\ "D:\Backup\MEDION\My PSTs" "My.pst" / 
copyall /np /r:0 /w:0 
--------------------------------------------------------------------------- ---- 
   ROBOCOPY     ::     Robust File Copy for Windows 
--------------------------------------------------------------------------- ---- 
  Started : Wed Jul 27 20:44:35 2011 
2011/07/27 20:44:35 ERROR 123 (0x0000007B) Getting File System Type of Source q:\ 
The filename, directory name, or volume label syntax is incorrect. 
   Source - q:\ 
     Dest : D:\Backup\MEDION\My PSTs\ 
    Files : My.pst 
  Options : /COPYALL /NP /R:0 /W:0 
--------------------------------------------------------------------------- --- 
NOTE : NTFS Security may not be copied - Source may not be NTFS. 
2011/07/27 20:44:35 ERROR 123 (0x0000007B) Accessing Source Directory 
q:\ 
The filename, directory name, or volume label syntax is incorrect. 

Since using Robocopy is the primary use case for ShadowSpawn, we need to figure out why it is failing.

Expected Behavior

When launched via ShadowSpawn, Robocopy should work the same as when launched without.

candera commented 13 years ago

Closing as “can’t repro”. It looks like this error is probably due to the fact that the robocopy command line has mismatched quotes. The changes we made for #6 should mean that this results in a usage error, making the mistake more clear.

candera commented 13 years ago

After further investigation, it looks like this is due to backup software being installed (see the email thread here ). It's possible that the issue is that it's picking up one of the other providers, which is not well-behaved. We need to figure out if we can specify which provider to use.

candera commented 13 years ago

Looks like IVssBackupComponents::AddToSnapshotSet has a place to select the backup provider. The OP provided this output of vssadmin list providers:

vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2005 Microsoft Corp.

Provider name: 'StorageCraft Volume Snapshot Software Provider'
  Provider type: Software
  Provider Id: {24602736-bed9-4619-91b0-243447c6409c}
  Version: 1.0.0.0

Provider name: 'Microsoft Software Shadow Copy provider 1.0'
  Provider type: System
  Provider Id: {b5946137-7b9f-4925-af80-51abd60b20d5}
  Version: 1.0.0.7

And some research on the Internet suggests that the StorageCraft provider can be problematic.

Currently, we're passing GUID_NULL to AddToSnapshot set, which may select the StorageCraft provider. By explicitly specifying the Microsoft provider, we may be able to avoid this problem.

candera commented 13 years ago

There's some information here that talks about how you use IVssBackupComponents::Query to find the GUID of the system default provider. We'll have to do something like that.