А указание WshShell.CurrentDirectory на WshShell.Exec влияние не оказывает?

Оказывает
С WshShell.CurrentDirectory = "D:\" отлично работает. Спасибо за подсказку.

P.S. Разработчика уже лет семь пинают на эту тему, но увы…

Почему?

Потому что 7z при отсутствии имени диска в списке файлов, 7z начинает искать файлы относительно места расположения скрипта. Через oShell.ShellExecute можно задать рабочую папку, через WshShell.Exec я такого способа не знаю(хотя это не значит что его нет). Пробовал заменить имя "D:\" на "..\..\..\"(такая у меня глубина расположения скрипта) - 7z опять пытается скинуть файлы в архив скопом. Поэтому или скрипт ложить в корень диска(я предпочитаю хранить скрипты структурированно) или использовать ShellExecute. Или пробывать связаться с разработчиком и пытаться протолкнуть новый ключ запуска .

P.S. кому интересно - 7-zip compress full paths from directory listing(реализация архивирования 7z со списка с полными путями на cmd)

Почему?

Есть много тикетов в "запрос фичи", есть в форумах.
Пока максимум что можно использовать описано в этом топике - Store Full Paths?. Если кратко - некоторое подобие функционала имеется(ниже опишу), однако на добавления ключа с полноценным функционалом пока автора не уговорили. Причина - расхождение в желаниях. Одни хотят полный путь хранить в архиве(начиная с "D:\"), другие согласны на исключение диска или замены диск на одноимённую папку. Однако воз и ныне там(скачал бету 9.22).
Суть недоделанного функционала в следующем. Допустим список файлов такой(сократил для краткости):

Убираем диск:

Запускаем создание архива из корня диска:
D:\>7z.exe a -t7z "D:\!2Burn\20111227.7z" @"D:\TEMP\archList.txt" -r- -up1q0r2x1y2z1w2  -scsWIN
Результат:

Правда запускать из скрипта уже придётся так:

Dim oShell
Set oShell = CreateObject("Shell.Application")
oShell.ShellExecute "7z.exe", "a -t7z """ & ArchName & """ @""" & ListFile & """" & ZipAttribs & " -scsWIN", "D:\", "", 1

Из минусов - код выхода кажется при таком запуске от 7z.exe не получить(если не путаю), и соответственно не обработать(жирный минус).
То что выше описано относится к "недокументированным" возможностям(в документации об этом упоминаний не видел). Хотя 7z сам не обновляется, но мне стрёмно такие вещи использовать .

Опробуете — отпишитесь, пожалуйста.

Работает всё кроме самого главного
При работе по списку 7z пытается скинуть все файлы в архив без учёта путей. Пытается - потому что в разных папках есть файлы с одинаковым именем, в результате:

Боюсь что пока соответствующий функционал не появится в архиваторе, красивая идея бэкапа через список сформированный логпарсером останется только идеей. Конечно создание структуры каталогов есть в WinRAR-е(структура начинается с корня исходного размещения файла), но он платный. Не свой же ключ на серваке использовать(да и нарушением лицензии это наверно будет). Правда установленная у меня версия 4.01 не работала с длинными путями, но после установки свежескачанной версии 4.00 стала работать

Ещё проблема(думаю баг) - 7z по дефолту использует UTF-8 файл-листы, однако(судя по возникающей ошибке) не понимает "что там за хрень" в начале файла - волшебные биты ему не нравятся:

Это лечится ключём -sсsWIN и сохранением файл-листа в ASCII.

В остальном всё замечательно .

Впрочем, если кому-то пригодится, вот "болванка"(практически без защиты от дурака - вроде слэшей в конце пути, существования папок и файлов, и т.д.):

' VB Script Document
Option Explicit

Dim SVNzip, OutPathZip
SVNzip = "C:\Program Files\7-Zip\7z.exe"
OutPathZip = "D:\!2Burn"

Dim WshShell, fso, ListFile, ts
Set WshShell = WScript.CreateObject("WScript.Shell")
Set fso = WScript.Createobject("Scripting.FileSystemObject")
ListFile = "D:\TEMP\archList.txt"
Set ts = fso.CreateTextFile(ListFile, True, False)

Dim oLogQuery, oInputFormat, strQuery, oRecordSet, oRecord
Set oLogQuery = WScript.CreateObject("MSUtil.LogQuery")
Set oInputFormat = WScript.CreateObject("MSUtil.LogQuery.FileSystemInputFormat")
strQuery = "select Path " & _
            "from 'd:\!pre_backup2\*.*' " & _
            "where " & _
            "EXTRACT_EXTENSION(Path) in ('doc'; 'docx'; 'docm'; 'xls'; 'xlk'; 'xlsx'; 'xlsm'; 'mdb'; 'adp'; 'rtf'; 'vbs'; 'pdf') " & _
            "and " & _
            "SUBSTR (EXTRACT_FILENAME (Path),0,1) Not In ('~')"
Set oRecordSet = oLogQuery.Execute(strQuery, oInputFormat)

Do While Not oRecordSet.atEnd
	Set oRecord = oRecordSet.getRecord
  ts.WriteLine(oRecord.getValue(0))
	oRecordSet.moveNext
Loop
oRecordSet.close
ts.Close

Dim ArchName, ZipAttribs, ExecSrting, oExec
ArchName = OutPathZip & "\" & LongDate(now) & ".7z"
ZipAttribs = " -r- -up1q0r2x1y2z1w2 "
ExecSrting = """" & SVNzip & """" & " a -t7z """ & ArchName & """ @""" & ListFile & """" & ZipAttribs & " -scsWIN"
WScript.Echo ExecSrting
Set oExec = WshShell.Exec(ExecSrting)
Do While oExec.Status = 0
  WScript.Sleep 100
Loop
Select Case oExec.ExitCode
  Case 0
    wscript.echo "All Done"
  Case 1
    wscript.echo "Warning (Non fatal error(s))."
  Case 2
    wscript.echo "Fatal error"
  Case 7
    wscript.echo "Command line error"
  Case 8
    wscript.echo "Not enough memory for operation"
  Case 256
    wscript.echo "User stopped the process"
End Select
'##############################################################################
' Возвращает дату(без времени) вида YYYYMMDD
Function LongDate(Data)
  Dim DD, MM, YYYY
  DD = CStr(Day(Data))
  MM = CStr(Month(Data))
  YYYY = CStr(Year(Data))
  If Len(DD) = 1 then DD = "0" & DD
  If Len(MM) = 1 then MM = "0" & MM
  LongDate = YYYY & MM & DD
End Function

В папку OutPathZip создаётся архив с именем YYYYMMDD.7z. Исходная папка и фильтры - в SQL-запросе, ListFile - расположение файл-листа.

В целом работает, но в хэлпе наткнулся на это:…

Да, сие, конечно, хреново: запятая и круглые скобки не редкость в именах файлов (сам я, правда, предпочитаю квадратные — «[]»). Но, с другой стороны — речь ведь идёт только об предикате «FROM» — тут ведь легко заранее озаботиться тем, чтобы ни запятых, ни скобок в пути не было.

Опробуете — отпишитесь, пожалуйста.

Может сгодится: Finding Path lengths greater than MAX_PATH.

Поизучаю - иногда приходится на дотнете писать для своих нужд, работа с длинными путями может пригодиться.

В целом работает, но в хэлпе наткнулся на это:

Если мой английский меня не подводит, то это значит что в поле FROM ссылающемся на путь(-i:FS) символ запятой недопустим в любом виде.
Будучи упёртым и недоверчивым попробовал все известные мне способы: \,, ^,, \u002C, %,, [,]. Даже задваивать запятую пробовал - уже как разделитель не бьётся, но ругается на то что путь инвалид(в пути двойная запятая - конечно инвалид). Хэлп не соврал .
Правда если путь в поле FROM без запятой, то работает - в результат выборки пути с запятой попадают. Так что вариант приемлимый с учётом этого ограничения.

@path\@file - получить путь и имя для длинного пути получается. Правда оба параметра в своей паре кавычек, но это вопрос второй. А первый - что с этим делать дальше . COPY сполна пользуется ограничением MAX_PATH. Если просто строить список файлов, то мне LogParser больше по душе(наверно за SQL-подобный синтаксис).

Так как объём дневных изменений невелик, наверно пока остановлюсь на robocopy, а при большом объёме изменяемых файлов вариант с логпарсером может дать экономию места, т.к. нет нужды в промежуточном копировании(надо будет протестировать как 7z с путями поступает при работе со списком файлов).

Речь про то, что с помощью LogParser можно сделать отбор по дате (если он действительно работает с длинными путями) и построить список файлов, который затем передать посредством текстового файла 7-zip'у:

То есть, что-то наподобие:

"C:\Program Files\Log Parser 2.2\LogParser.exe" "SELECT Path FROM "E:\Песочница\0099\*.*", "E:\Песочница\0100\*.*", "E:\Песочница\0101\*.*" WHERE LastWriteTime >= TO_LOCALTIME(SUB(SYSTEM_TIMESTAMP(), TIMESTAMP('0000-01-02', 'yyyy-MM-dd'))) AND Attributes NOT LIKE 'D________'" -i:FS -q:ON -oCodepage:65001 -recurse:0 1>Out.txt

(или аналогичный запрос на WSH).

С более ранними версиями могут быть проблемы на длинных путях:

Забавно - поддержку длинных путей можно отключить(зачем?!) если запускать с ключём /256.
Документация к ней правда своеобразная, но разобраться можно.

Есть GUI(отдельно качать), пользы от которого ноль - всё равно назначения ключей в документации читать нужно.
P.S. Что примечательно, Майкрософт сообщил что есть у них новая утилита - RichCopy tool. Правда длинные пути не переварила, и с консоли похоже не работает .
P.P.S. если всё-таки есть полноценный костыль для VBS для работы с длинными путями, то информация мне всё ещё интересна(хотя текущую задачу буду решать через robocopy - то что сейчас нужно он делать умеет).
_______________________________
Update: Ключи запуска с консоли у RichCopy tool всё-таки есть, а длинные пути похоже в задумках(тема о преодолении ограничения WinAPI MAX_PATH, судя по форумам, ну ооочень бородатая - почему не сделать наконец поддержку длинных путей, ума не приложу):

Собственно причина изысканий - объём бэкапа стал такой, что два архива на болванку перестали помещаться. Хотел делать бэкап инкриментно. Сначала полный архив(с записью на болванку), потом каждый день скидывать на болванку изменившиеся документы. Для этого и нужно "собирать" по каталогам файлы не только по маске, но и по дате изменения.

Вариант использования административных мер(предупредить юзеров о необходимости не злоупотреблять вложенностью и длиной имени файлов) оставляю на последок. А пока буду ещё думать над разумными костылями для решения этой задачи. Надо посмотреть как там с длиной пути в php .

А вот идея с короткими(8.3) именами на удивление сработала(Rom5, благодарю за идею) - сначала создал папку по полному пути, получил её в виде объекта. При копировании подставил короткий путь:

NewFile = fldr.ShortPath & "\" & File.Name

Файл нормально скопировался, полное имя с путём - 269 символов. Впрочем, радость моя была неполной - создать папку с путём длиннее 260(259) символов тоже не выходит. Сейчас самый длинный путь 209 символов, но нет никаких гарантий что он не станет длиннее. Создавать же целевой каталог изначально в виде 8.3 не подходит - это скрипт для бэкапа, нужно сохранить структуру полностью(начало названия папки может совпадать и в формате 8.3 придётся перебирать их поочереди, а название файла юзеры помнят всегда очень приблезительно).

Похоже придётся обратить свой взор в сторону дотнета... Надеюсь там этого ограничения уже нет .

Столкнулся с ситуацией - при копировании файла, если полное имя TargetFile больше определённой весьма конечной длины, возникает ошибка 76(Путь не найден). Причём ошибка возникает только при превышении длины для конечного файла(исходный файл может иметь полный путь и длиннее).
Поиск дал информацию об ограничении в WinAPI в 260 символов(259 видимых, если не ошибаюсь) - Maximum Path Length Limitation. Есть рекомендация для длинного пути использовать в пути префикс "\\?\", но похоже рекомендация к скриптам не относится, т.к. в скрипте не срабатывает(Ошибка выполнения Microsoft VBScript: Недопустимый вызов или аргумент процедуры).

Собственно вопрос - можно ли в vbscript обойти данное ограничение?

Подрезать конечный путь в некоторых пределах я могу, но проблему это не решит(научить пользователей лаконичности при создании структуры в общей папке, ИМХО,  невозможно).

P.S. файловая система NTFS, OS - Windows Server 2003 SE R2 SP2.
P.P.S. попробовал консольные утилиты: xcopy -  пишет "Недостаточно памяти"; проверил copy - "Указано слишком длинное имя файла.". Решил вернуться к nnbackup - "Имя файла или его расширение имеет слишком большую длину." Прям засада какая-то .

OFFTOP: есть-ли такое ограничение в .NET, или хотя бы там получится работать с длинными путями?