Comments 18
Когда ж они научат explorer-то работать с длинными путями. С sharepoint и onedrive из-за этого имеем целую кучу неприятностей
Добавим — когда они научат Powershell работать с длинными путями. Вот еще один источник головной боли.
Что это, господа? gallery.technet.microsoft.com/scriptcenter/Function-to-get-file-and-475aeb3a
Обертка для Powershell с использованием Robocopy.
Что это, господа? gallery.technet.microsoft.com/scriptcenter/Function-to-get-file-and-475aeb3a
Обертка для Powershell с использованием Robocopy.
никогда, потому что поддерживают совместимость
с древними временами, когда MAX_PATH был выставлен в 260 символов.
Ставьте перед путём префикс \\?\ и будет вам счастье — тот же Explorer будет обрабатывать пути хоть по 30 тыс. символов длиной.
с древними временами, когда MAX_PATH был выставлен в 260 символов.
Ставьте перед путём префикс \\?\ и будет вам счастье — тот же Explorer будет обрабатывать пути хоть по 30 тыс. символов длиной.
Ошибся веткой. В Powershell Get-ChildItem не принимает префикс, поэтому практическая польза от него довольно условная. Explorer тоже не заставишь работать с «длинными» именами, кроме как сделав subst.
Проблема с длинными путями в Windows несколько глубже, чем кажется, и просто так, префиксами, не решается.
Да вот если бы из этого тайного знания можно было бы извлечь практическую пользу.
PS C:\Users\Michael> Get-ChildItem \\.\c:\temp
Get-ChildItem : Данный формат пути не поддерживается.
PS C:\Users\Michael> Get-ChildItem \\?\c:\temp
Get-ChildItem : Путь содержит недопустимые знаки.
PS C:\Users\Michael> Get-ChildItem c:\temp
Get-ChildItem : Слишком длинный путь или имя файла. Полное имя файла должно содержать меньше 260 знаков,
У нас были большие проблемы с robocopy, в результате чего мы пришли к обратному выводу. Он молча пропускал файлы с проблемами в кодировке имени. Как такие файлы у нас образовались, это другой вопрос, но факт остаётся фактом. В итоге написали утилиту копирования на JScript. И смех и грех.
(ошибся веткой)
Только не 255 а 260:
msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath
Более того Explorer не даст вам создать такой файл. Я думаю это сделано специально для обратной совместимости, чтобы после работы с файлами в Explorer вы по прежнему могли открыть его во всех старых программах.
Ну а почему неправильно считает — это отдельный вопрос.
msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath
Более того Explorer не даст вам создать такой файл. Я думаю это сделано специально для обратной совместимости, чтобы после работы с файлами в Explorer вы по прежнему могли открыть его во всех старых программах.
Ну а почему неправильно считает — это отдельный вопрос.
А Far или WinCommander какой при этом результат дают?
А можете помочь найти файлы в следующем сценарии? Берем системный раздел, либо символьную ссылку на VSS снэпшот системы. Копируем через robocopy файлы на другой раздел. Пробовал и вашей командой и так >robocopy c:\system\vss2\ f:\ /MIR /R:1 /W:1 /log:«g:\r
obo.txt». На исходном разделе c: 50ГБ занято, 100ГБ общий размер раздела. Через некоторое время работы смотрю свойства раздела f: (тоже размер 100ГБ) и вижу: свободно 17ГБ, занято 83Гб. Захожу туда эксплорером, считаю общий размер всех файлов 4.5ГБ. Предполагаю что robocopy разворачивает символьные ссылки Documents and settings оставленные для совместимости в бесконечное вложение. Но в эксплорере эта папка почти пустая. А в консоли вообще не видна.
obo.txt». На исходном разделе c: 50ГБ занято, 100ГБ общий размер раздела. Через некоторое время работы смотрю свойства раздела f: (тоже размер 100ГБ) и вижу: свободно 17ГБ, занято 83Гб. Захожу туда эксплорером, считаю общий размер всех файлов 4.5ГБ. Предполагаю что robocopy разворачивает символьные ссылки Documents and settings оставленные для совместимости в бесконечное вложение. Но в эксплорере эта папка почти пустая. А в консоли вообще не видна.
Вот что нашел по этому поводу
Мне кажется весьма ценная информация, которые было бы неплохо указывать в офф. документации к утилите, а не искать по всему гуглу.
This was surprisingly tricking issue to deal with. If you are copying TO or FROM a Deduplicated file share you must make certain:
- Do NOT robocopy the a partition or volume – only robocopy shares\folders. This is because the dedup information is stored in the SYSTEM VOLUME INFORMATION folder and at folder can not be migrated with robocopy. It needs to be built on the partition\volume that the dedup exists on.
- Make sure you do NOT use /XJ switch. XJ is Exclude Junction points and junction points (JP’s) are tied into the deduplication process. In previous versions of Windows, starting with Vista, I have needed to use /XJ because if robocopy hit tried to copy a JP’s the destination disk would fill up with thousands of nested folders matching the name of the JP. Worse this problem was not readily recoverable by deleting those folders, even using the old POSIX commands. The only solution, according to Microsoft Partner Support (and from my experience) was to reformat the disk… not cool.
Мне кажется весьма ценная информация, которые было бы неплохо указывать в офф. документации к утилите, а не искать по всему гуглу.
Вот такая есть еще милая KB
FSRM and Data Deduplication may be adversely affected when you use Robocopy /MIR in Windows Server 2012
FSRM and Data Deduplication may be adversely affected when you use Robocopy /MIR in Windows Server 2012
Sign up to leave a comment.
Где мои файлы, ROBOCOPY?