Я могу направить файл, а он не существует, но размещение его каталога или файла в том же каталоге, что и он, работает нормально.
Это аппаратная или программная проблема? Если аппаратно, то это привод или что-то похуже?
2013-06-13 9:35 C:\>dir E:\Shares\Users\Test\Desktop\XAV-1.htm
Volume in drive E is BKUP2013-1
Volume Serial Number is 1AEA-6007
Directory of E:\Shares\Users\Test\Desktop
File Not Found
Все же:
2013-06-13 9:36 C:\>dir E:\Shares\Users\Test\Desktop
Volume in drive E is BKUP2013-1
Volume Serial Number is 1AEA-6007
Directory of E:\Shares\Users\Test\Desktop
2013-06-12 07:15 PM <DIR> .
2013-06-12 07:15 PM <DIR> ..
[snip]
2006-05-04 03:48 PM 1,232 Customer Files.lnk
2009-09-03 09:06 AM 767 Internet Explorer.lnk
2010-03-11 09:49 AM 104 My Computer.lnk
2004-01-02 04:50 PM 1,221 Reference Material.lnk
2011-11-18 05:08 PM 482 Shortcut to Downloads.lnk
2013-04-27 03:07 AM <DIR> Unused Desktop Shortcuts
2013-06-12 02:41 PM 2,710 XAV-1.htm
2011-01-10 03:31 PM 21,637,284 XP_EzTrends_1.0.3835.exe
11 File(s) 27,977,417 bytes
3 Dir(s) 670,902,140,928 bytes free
И родной брат:
2013-06-13 9:36 C:\>dir E:\Shares\Users\Test\Desktop\XP_EzTrends_1.0.3835.exe
Volume in drive E is BKUP2013-1
Volume Serial Number is 1AEA-6007
Directory of E:\Shares\Users\Test\Desktop
2011-01-10 03:31 PM 21,637,284 XP_EzTrends_1.0.3835.exe
1 File(s) 21,637,284 bytes
0 Dir(s) 670,902,140,928 bytes free
Кроме того, я могу без проблем открыть XAV-1.htm, и он имеет тот же профиль ACL, что и XP_EzTrends ... exe.
Что касается ACL, если я щелкну правой кнопкой мыши диски C: или E: в «Мой компьютер» и выберу «Безопасность», оба они покажут СИСТЕМУ как имеющую полный доступ. Насколько я понимаю, это относится к NT AUTHORITY\SYSTEM. ОБНОВИТЬ: Более того, ACL примерно такой же, как и на старом диске, который мы использовали для E :, который теперь слишком мал для нас. Я подключил его и проверил, и во всяком случае, ACL более строгий на старом диске, с доступом только для чтения для пользователей. Однако для СИСТЕМЫ, Все и Администраторы как старые, так и новые разрешают полный доступ. (Что, возможно, слишком свободно, но это даже больше похоже на «должно работать».) ОБНОВЛЕНИЕ 2: Я включил аудит и проверил журнал событий, который если это похоже на 2008 год должен сделать событие в журнале безопасности с категорией Object Access, но в моем журнале безопасности ничего подобного нет. Интересно, если сноска Вот насчет политики домена здесь применяется козырная политика, даже если это на контроллере домена. ОБНОВЛЕНИЕ 3: Хорошо, мне удалось получить Object Access записи для отображения, включив ведение журнала доступа к объектам в целом в областях политики домена / контроллера домена, в дополнение к его запросу в конкретной папке для всех, меня и СИСТЕМЫ для любого типа доступа. Однако при выполнении резервного копирования никаких записей не создается, они поступают с помощью оснастки MMC.
ОБНОВЛЕНИЕ 4: Я изменил сценарий резервного копирования на ручную побайтовую проверку всех файлов в каталоге Desktop в дополнение к случайной статистической выборке, которую он обычно делает, и переформатировал диск в exFAT, чтобы каждый файл копировался с нуля. Я только получил Success Audit Object Access записи, когда эти файлы были затронуты на этапе проверки. Сейчас я пробую то же самое на втором из двух дисков, который казался более нестабильным, так что посмотрим, что там написано.
ОБНОВЛЕНИЕ 5: Как ни странно, пользователи Test и SYSTEM имеют чередование Success Audit записи из во время резервного копирования для каталога рабочего стола. Но никаких сбоев. Тем временем я наблюдаю, как ROBOCOPY делает свое дело, и у него не было проблем с хорошей частью резервной копии. Теперь он терпит неудачу для каждого файла, начиная с этого (последний успешный файл и первые два неудачных - с тех пор он, кажется, делает серии успехов и неудач):
\C\Rebuild\Apache\httpd-2.2.24-win32\Apache2\modules\mod_version.so
New File 11776 2013/02/25 20:09:27 C:\scheduled\res \C\Rebuild\Apache\httpd-2.2.24-win32\Apache2\modules\mod_vhost_alias.so
New Dir 4 C:\scheduled\res\C\Rebuild\Backup\
New File 14.7 m 2010/12/01 17:09:00 C:\scheduled\res \C\Rebuild\Backup\cbSetup.exe 2013/07/10 17:37:04 ERROR 3 (0x00000003) Copying File C:\scheduled\res\C\Rebuild \Backup\cbSetup.exe The system cannot find the path specified. Waiting 1 seconds... Retrying...
New File 14.7 m 2010/12/01 17:09:00 C:\scheduled\res \C\Rebuild\Backup\cbSetup.exe 2013/07/10 17:37:06 ERROR 3 (0x00000003) Copying File C:\scheduled\res\C\Rebuild \Backup\cbSetup.exe The system cannot find the path specified. Waiting 1 seconds... Retrying...
New File 14.7 m 2010/12/01 17:09:00 C:\scheduled\res \C\Rebuild\Backup\cbSetup.exe 2013/07/10 17:37:08 ERROR 3 (0x00000003) Copying File C:\scheduled\res\C\Rebuild \Backup\cbSetup.exe The system cannot find the path specified. Waiting 1 seconds... Retrying...
New File 14.7 m 2010/12/01 17:09:00 C:\scheduled\res \C\Rebuild\Backup\cbSetup.exe 2013/07/10 17:37:09 ERROR 3 (0x00000003) Copying File C:\scheduled\res\C\Rebuild \Backup\cbSetup.exe The system cannot find the path specified.
ERROR: RETRY LIMIT EXCEEDED.
New File 2.0 m 2010/03/04 16:18:28 C:\scheduled\res \C\Rebuild\Backup\diffutils-2.8.7-1.exe 2013/07/10 17:37:10 ERROR 3 (0x00000003) Copying File C:\scheduled\res\C\Rebuild \Backup\diffutils-2.8.7-1.exe The system cannot find the path specified. Waiting 1 seconds... Retrying...
New File 2.0 m 2010/03/04 16:18:28 C:\scheduled\res \C\Rebuild\Backup\diffutils-2.8.7-1.exe 2013/07/10 17:37:11 ERROR 3 (0x00000003) Copying File C:\scheduled\res\C\Rebuild \Backup\diffutils-2.8.7-1.exe The system cannot find the path specified. Waiting 1 seconds... Retrying...
New File 2.0 m 2010/03/04 16:18:28 C:\scheduled\res \C\Rebuild\Backup\diffutils-2.8.7-1.exe 2013/07/10 17:37:12 ERROR 3 (0x00000003) Copying File C:\scheduled\res\C\Rebuild \Backup\diffutils-2.8.7-1.exe The system cannot find the path specified. Waiting 1 seconds... Retrying...
New File 2.0 m 2010/03/04 16:18:28 C:\scheduled\res \C\Rebuild\Backup\diffutils-2.8.7-1.exe 2013/07/10 17:37:13 ERROR 3 (0x00000003) Copying File C:\scheduled\res\C\Rebuild \Backup\diffutils-2.8.7-1.exe The system cannot find the path specified.
ERROR: RETRY LIMIT EXCEEDED.
И все еще:
2013-07-1017:45 C:\>dir C:\scheduled\res\C\Rebuild\Backup\cbSetup.ex
Volume in drive C has no label.
Volume Serial Number is 3C18-E114
Directory of C:\scheduled\res\C\Rebuild\Backup
2010-12-01 01:09 PM 15,492,608 cbSetup.exe
1 File(s) 15,492,608 bytes
0 Dir(s) 240,190,017,536 bytes free
2013-07-1017:45 C:\>dir C:\Rebuild\Backup\cbSetup.exe
Volume in drive C has no label.
Volume Serial Number is 3C18-E114
Directory of C:\Rebuild\Backup
2010-12-01 01:09 PM 15,492,608 cbSetup.exe
1 File(s) 15,492,608 bytes
0 Dir(s) 239,572,938,752 bytes free
2013-07-1017:46 C:\>
ОБНОВЛЕНИЕ 6: Еще страннее, похоже, что он действительно скопировал файл, от которого якобы отказался, и со странной меткой даты (что он сделал для своих файлов-братьев в том же каталоге):
2013-07-1017:46 C:\>dir e:\IN\Rebuild\Backup\cbSetup.exe
Volume in drive E is BAERO2013-2
Volume Serial Number is 76F0-668E
Directory of e:\IN\Rebuild\Backup
1980-01-01 08:00 PM 15,492,608 cbSetup.exe
1 File(s) 15,492,608 bytes
0 Dir(s) 822,191,718,400 bytes free
2013-07-1018:05 C:\>
И для тех, у кого я почти уверен, что не произошла ошибка (это уже прошлое, к чему я могу вернуться в командном окне), у случайного небольшого количества из них испорчена их временная метка (ROBOCOPY помечает их как неполные):
2013-07-1018:05 C:\>dir e:\IN\Rebuild\Apache
Volume in drive E is BAERO2013-2
Volume Serial Number is 76F0-668E
Directory of e:\IN\Rebuild\Apache
2013-07-10 05:36 PM <DIR> .
2013-07-10 05:36 PM <DIR> ..
1980-01-01 08:00 PM 6,042,112 httpd-2.2.15-win32-x86-openssl-0.9.8m-r2.msi
2013-07-10 05:36 PM 80 httpd-2.2.15-win32-x86-openssl-0.9.8m-r2.msi.md5
1980-01-01 08:00 PM 6,085,632 httpd-2.2.17-win32-x86-openssl-0.9.8o.msi
2013-07-10 05:36 PM 76 httpd-2.2.17-win32-x86-openssl-0.9.8o.msi.md5
1980-01-01 08:00 PM 9,097,535 httpd-2.2.23-win32-ssl_0.9.8.zip
1980-01-01 08:00 PM 9,257,408 httpd-2.2.24-win32.zip
2012-11-06 05:23 AM 2,251 service-dependencies--unused.reg
2010-10-20 07:51 AM 2,410 services.bat
2013-05-28 06:57 AM 2,665 services-splittest.bat
2012-11-06 05:58 AM 2,448 services-upgradetest.bat
2013-07-10 05:36 PM <DIR> httpd-2.2.24-win32
10 File(s) 30,492,617 bytes
3 Dir(s) 821,313,273,856 bytes free
2013-07-1018:07 C:\>
Тем не менее, как вы можете видеть, файлы на C в теневой копии тома C, резервная копия которой выполняется ROBOCOPY, и файлы E, отформатированные непосредственно перед запуском ROBOCOPY, побайтно идентичны с помощью cmp.exe:
2013-07-1018:13 C:\>c:\scheduled\res\cmp.exe --verbose c:\scheduled\res\C\Rebuild\Apache\httpd-2.2.24-win32.zip e:\IN\Rebuild\Apache\httpd-2.2.24-win32.zip
2013-07-1018:13 C:\>c:\scheduled\res\cmp.exe --verbose c:\Rebuild\Apache\httpd-2.2.24-win32.zip e:\IN\Rebuild\Apache\httpd-2.2.24-win32.zip
2013-07-1018:13 C:\>
ОБНОВЛЕНИЕ 7: Теперь я вижу некоторые файлы идут, говоря The process cannot access the file because it is being used by another process. и другие говорят The system cannot find the path specified.. Оба сообщения кажутся отвлекающими, потому что я запускаю ROBOCOPY с / B, что означает, что он работает как Оператор резервного копирования и должен иметь доступ ко всем локальным файлам, что и есть. Также я смотрю на оснастку Open Files MMC, а их нет. Я даже использовал LockHunter для одного из файлов, "используемых другим процессом" сразу после того, как он пожаловался, и LockHunter никогда не терпел неудач, по моему опыту, но он говорит, что его никто не использует. Я выгнал всех пользователей, и я единственный, кто вошел в систему, и я, конечно же, не касаюсь случайных групп файлов, подобных этому. Я отключил планировщик задач и убедился, что мой robocopy - единственный запущенный сейчас процесс robocopy.
ОБНОВЛЕНИЕ 8: После переформатирования в exFAT я не пробовал CHKDSK /R, так я и сделал. Он говорит, что 0 КБ в битых секторах через 7 часов (это диск на 1 ТБ).
Это на внешнем USB-накопителе WD недельной давности. Пора вернуть? Или у нас порт USB идет? Или что?
ОБНОВЛЕНИЕ 9: Мы только что попробовали взять напрокат диск емкостью 1 ТБ от местного предприятия, который представляет собой USB 2.0 вместо USB 3.0, как и наши прежние диски (но большего размера). Он не демонстрирует того же поведения, что и исходный вопрос, но во время резервного копирования на этапе проверки произошел сбой, заявив, что файл не существует на E :, хотя после этого он существует, и я могу направить его самостоятельно, в отличие от выше.