- 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
-
Изменено
Перейти к контенту
- 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
- Изменено
Hi All,
the last days I’ve been banging my head why my self-made robocopy back-up script isn’t working anymore since using it on server 2016. I’ve been using this script on 2008/2008R2/2012/2012R2 succcesfully but on Server 2016 it won’t.
I’ve troubleshooted the issue down to a simple method so it can be verified:
Script robocopy local directory (on 2016 server) c:test to share (on server 2012R2 «serverdfs-share»
ERROR 123 (0x0000007B) Accessing Destination Directory: c:windowssystem32robocopy.exe «c:test» «serverdfs-sharetest»
Also, after I run the command, it deletes the folder «test» when it is empty.
When I create a share on the 2012R2 volume without the use of DFS, the robocopy works perfectly. Also, when i run the robocopy script from a 2012R2 server to the DFS share it works perfectly.
I’ve also set the share-rights and ntfs rights to Everyone:FULL.
I’ve searched a lot, but I cannot find any issues which are the same as my issue.
Can someone please help me out here?
Hi All,
the last days I’ve been banging my head why my self-made robocopy back-up script isn’t working anymore since using it on server 2016. I’ve been using this script on 2008/2008R2/2012/2012R2 succcesfully but on Server 2016 it won’t.
I’ve troubleshooted the issue down to a simple method so it can be verified:
Script robocopy local directory (on 2016 server) c:test to share (on server 2012R2 «serverdfs-share»
ERROR 123 (0x0000007B) Accessing Destination Directory: c:windowssystem32robocopy.exe «c:test» «serverdfs-sharetest»
Also, after I run the command, it deletes the folder «test» when it is empty.
When I create a share on the 2012R2 volume without the use of DFS, the robocopy works perfectly. Also, when i run the robocopy script from a 2012R2 server to the DFS share it works perfectly.
I’ve also set the share-rights and ntfs rights to Everyone:FULL.
I’ve searched a lot, but I cannot find any issues which are the same as my issue.
Can someone please help me out here?
I have a batch file that runs a robocopy to copy a quickbooks file from one pc to another, no domain or anything — very basic setup. Both PCs running win7.
Running the file
@echo off
if exist x: (net use x: /delete)
net use x: 192.168.1.11qbbackupquickbooks /user:user password
robocopy c:quickbooksFnBNEW2012.qbw 192.168.1.11qbbackupquickbooksFnBNEW2012.qbw /MIR
pause
Gives me the error
2012/08/02 19:31:22 ERROR 123 (0x0000007B) Accessing Source Directory c:quickbo
oksFnBNEW2012.qbw
This was working fine for a few months and then stopped for some reason. Its interesting that the error adds a at the end of the file even though its not in my script. Also, I have tried using quotes around one or both of the source and destination paths and got the same result. I can manually copy/paste (drag/drop) the file without any issues. I have had issues with this in the past using other copy commands (xcopy and copy) and they seemed to work for a little then stop again. I tried xcopy and it gives me «sharing violation». I have permissions on the c:quickbooks folder set to everyone full, guest full, and all the users that are used to full…still no luck! Should be so easy!
Note — I mapped the drive as x, then did a copy from c:path to x: — this is how it was setup and running without issues for a while, today I changed to unc path per a few google searches.
I’m using robocopy on a Windows10 computer without any problem.
I copied my bat file to a windows11 computer and can’t make it run because of this error:
C:Usersdidie.spyder-py3>robocopy ÔǬ»C:Usersdidie.spyder-py3″ «C:UsersdidieShadowDriveSauvegarde-.spyder-py3» /E /S /Z /FFT /NP /NDL /NS /NFL /NC /MT:8
2022/09/05 15:04:15 ERREUR 123 (0x0000007B) Accès au répertoire source C:Usersdidie.spyder-py3ÔǬC:Usersdidie.spyder-py3
La syntaxe du nom de fichier, de répertoire ou de volume est incorrecte.
i.e. ERROR 123 (0x0000007B) Accessing Destination Directory …
The filename, directory name, or volume label syntax is incorrect.
Here is my one-line bat file:
echo "start"
robocopy "C:Usersdidie.spyder-py3" "C:UsersdidieShadowDriveSauvegarde-.spyder-py3" /E /S /Z /FFT /NP /NDL /NS /NFL /NC /MT:8
:: robocopy C:"Usersdidie.spyder-py3" D:"SauvegardesSauvegarde-.spyder-py3" /E /S /Z /FFT /NP /NDL /NS /NFL /NC /MT:8
pause
If anybody knows the trick to make it work…
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.
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.