винда, как обычно
И о копировании, резервном и не очень.
Делаю XCOPY /S каталогу с 100000 файлов, 11000 папок. XCOPY пыхтит, но копирует. Делаю XCOPY /S другому каталогу, с 65000 файлов, 2300 папок. XCOPY копирует 4533 файла и вылетает с ошибкой "недостаточно памяти", воспроизводимость на этом наборе файлов 100%. Win10 pro x64, памяти 256Gb плюс своп (да, я маньяк). "Щито??"
Тщательное исследование методом "деления папки пополам" показало, что XCOPY падает с нехваткой памяти когда ей попадается файл с общей (путь+имя) длиной имени больше 256 символов. Файлы с длинным именем изолировал в отдельную папку, проверил - да, именно на них падает.
То есть чтобы работать с файлами с длиной имени 256 Байт (окей, 512 байт в юникоде), XCOPY не хватает объёма памяти в 256 ГИГАБайт - это, на минуточку, девять ноликов разницы, в миллиард раз! Это что мне, пару терабайт памяти что ли ставить, чтобы один файлик скопировать?
Хотя на самом деле это, конечно, вбитое руками статическое ограничение на длину пути, плюс не так давно появившаяся у микрософта традиция - при возникновении ошибки не пытаться сообщить пользователю, что произошло на самом деле, а просто выдать наиболее часто встречающуюся в этом месте причину ошибки, по принципу "авось угадали, а не угадали да и х.. с ним".
Но 256 символов для XXI века и 64-битной системы (XCOPY тоже 64-битное, я проверил) - это вообще свежо и оригинально. Думаю, это даже не с QDOS тянется, а вообще с CP/M 1974 года. Вот прям не удивлюсь, если в где-то в глубинах исходников XCOPY десятой винды обнаружится строчка "(с) 1973, Gary Kildall"...
А я ведь ещё помню, как в ~1998 году меня раздражало то, что в шелле FreeBSD 2.2.6 длина команды ограничена не то 32767, не то 65535 символами, и команды вида "rm *" на больших каталогах не работают, т.к. раскрытие "*" не помещается в строку...
Делаю XCOPY /S каталогу с 100000 файлов, 11000 папок. XCOPY пыхтит, но копирует. Делаю XCOPY /S другому каталогу, с 65000 файлов, 2300 папок. XCOPY копирует 4533 файла и вылетает с ошибкой "недостаточно памяти", воспроизводимость на этом наборе файлов 100%. Win10 pro x64, памяти 256Gb плюс своп (да, я маньяк). "Щито??"
Тщательное исследование методом "деления папки пополам" показало, что XCOPY падает с нехваткой памяти когда ей попадается файл с общей (путь+имя) длиной имени больше 256 символов. Файлы с длинным именем изолировал в отдельную папку, проверил - да, именно на них падает.
То есть чтобы работать с файлами с длиной имени 256 Байт (окей, 512 байт в юникоде), XCOPY не хватает объёма памяти в 256 ГИГАБайт - это, на минуточку, девять ноликов разницы, в миллиард раз! Это что мне, пару терабайт памяти что ли ставить, чтобы один файлик скопировать?
Хотя на самом деле это, конечно, вбитое руками статическое ограничение на длину пути, плюс не так давно появившаяся у микрософта традиция - при возникновении ошибки не пытаться сообщить пользователю, что произошло на самом деле, а просто выдать наиболее часто встречающуюся в этом месте причину ошибки, по принципу "авось угадали, а не угадали да и х.. с ним".
Но 256 символов для XXI века и 64-битной системы (XCOPY тоже 64-битное, я проверил) - это вообще свежо и оригинально. Думаю, это даже не с QDOS тянется, а вообще с CP/M 1974 года. Вот прям не удивлюсь, если в где-то в глубинах исходников XCOPY десятой винды обнаружится строчка "(с) 1973, Gary Kildall"...
А я ведь ещё помню, как в ~1998 году меня раздражало то, что в шелле FreeBSD 2.2.6 длина команды ограничена не то 32767, не то 65535 символами, и команды вида "rm *" на больших каталогах не работают, т.к. раскрытие "*" не помещается в строку...