- Remove From My Forums
-
Общие обсуждения
-
Много лет пользуюсь robocopy, но сейчас столкнулся со странной проблемой. Есть сервер, работающий под Windows 2008R2, он же RODC, хотя это и не важно. Переношу данные. Синтаксис самый обыкновенный, уже много раз опробованный robocopy.exe «O:WorkFiles-02IM»
«E:DATAWorkFiles-04IM» /MIR /COPY:DATSO /DCOPY:T /NP /R:5 /log:C:cmdcopy_mirror_wf_IM.log Получаю множественные ошибки типа: 2011/12/07 17:36:21 ERROR 123 (0x0000007B) Accessing Destination Directory O:WorkFiles-02IME_MAILEditorialTEST The filename,
directory name, or volume label syntax is incorrect. или New File 74346 P7270023.JPG 2011/12/07 17:37:00 ERROR 123 (0x0000007B) Accessing Destination Directory O:WorkFiles-02IMMarketingLifti7 The filename, directory name, or volume label syntax is incorrect.
Судя по тому, что я находил в интернет, такая проблема бывают у людей, которые ставят замыкающий слеш в пути, но у меня-то его нету! Более того, процентов 90% копируется, не копируется только часть, причем принцип мне совершенно непонятен. Те же файлы и папки
вручную копируются без проблем P.S. Не понимаю, что происходит с форматированием этого сообщения, после отправки слетают все переводы строки и русская буква м превращается в набор символов.-
Изменено
8 декабря 2011 г. 9:19
-
Изменен тип
Vinokurov Yuriy
21 декабря 2011 г. 8:24
-
Изменено
I recently enlisted the help of the Spiceworks community to help with a file migration that using Robocopy. First round went well with files and permissions being copied properly. Since I was doing this in phases because of the limited window I will have to make the switch for the users. Here is the scenario:
- Source — Server 2003 Enterprise 32 bit hosting a Share with files shared among all users in the company.
- Destination — Server 2012 64 bit (of course) which will host the new Shares for which I will eventually do DFS.
- Running Robocopy for the Destination server using the following command
Robocopy \Server1Group H:sharesGroup /b /copyall /MT:25 /MIR /R:2 W:5 /log+:c:Migrationloggrouplog.txt
So on the destination server I run the command prompt elevated as administrator while logged in as the Domain admin and a minute or 2 later I see that the process has ended because activity is passed back to the prompt. I check the log and see that there is an error:
2013/10/15 04:41:27 ERROR 123 (0x0000007B) Scanning Source Directory \server12share
The filename, directory name, or volume label syntax is incorrect.
Attempted solutions:
- Added my account to the Backup Operators group for both the source and destination servers, as well as the domain builtin Backup Operators group. Still not go.
- I figured the permissions were preventing reading the source (weird since I did a first run already successfully) so at the prompt I did «net use \server1share /user:xxx pass». Still no go.
- Server 2012 is weird in that it wont recognize mapped drives at the prompt so I did a «net use x: \server1share» and rerun the Robocopy command with the newly mapped rive letter, but still got the syntax error above.
I ran into the same problem while migrating another drive and ended up just wiping out the destination folder and running the same command (with /R:0 and /W:0) which worked fine.
Any help you guys can offer would be really appreciated because I am at the point where I will just do a straight copy/paste, cross my fingers and manually redo all the permissions.
Background
A user reports here that launching Robocopy via ShadowSpawn results in the error
D:BAT>D:SoftwareShadowSpawnW7x64ShadowSpawn.exe "C:UsersJohnDocumentsOutloo~1" q: robocopy q: D:BackupMEDIONMy PSTs" "My.pst" /copyall /np /r:0 /w:0
ShadowSpawn (c) 2011 Craig Andera. shadowsp...@wangdera.com
Shadowing C:UsersJohnDocumentsOutloo~1 at q:
Launching command: robocopy q: "D:BackupMEDIONMy 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:BackupMEDIONMy 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.
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.
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.
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.
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.