Pull to refresh

Comments 18

Когда-то все мануалы по оптимизации NTFS содержали совет выключить генерацию кототких путей на файловой системе, т.к. это якобы DOS-Legacy и нечего заводить для них лишние записи в Directory.

Ты хочешь пользоваться благами цивилизации и начать выполнять задачи быстрее — ты покупаешь компьютер машину.
Но пользование машиной — штука сложная. И пользоваться ей так как тебе вздумается: создавать файлы длиной 248 символов ездить по всюду на максимальной скорости 200 (несмотря на то, что машина может) — нельзя, раскидывать свои файлы по не предназначенным для этого папкам ездить по любой ровной поверхности, газонам и встречке — нельзя.
Ты идешь учиться водить и принимать правила и ограничения, которые позволяют безопасно существовать в соседстве с другими водителями: нельзя создавать миллион вложенных папок и длинных имен файлов ехать быстрее 60кмч по городу, нужно писать имена на латинице без пробелов, а не китайскими иероглифами придерживаться понятной для других водителей схемы оповещения, моргая поворотниками и включая фонари.
То, что компьютер машина "позволяет" делать — не значит, что это можно делать везде, а не только в сферической папке в вакууме на испытательном или гоночном треке.


Мораль: карать ректально просвещать любого, кто не следует сложившимся правилам.

Давайте я тоже попробую.
Есть две операционных системы машины: Windows и Linux красная и синяя.
Ими можно пользоваться как тебе вздумается, например создавать файлы с той длиной имени, которую поддерживает файловая система ездить по городу с максимальной разрешенной скоростью. Тем более что памяти уже не 16 килобайт колеса давно делают не из дерева, и ее хватит на путь любой длины они не отвалятся, если ехать на них быстрее 10 километров в час.
Но если Linux синяя делает это нормально, то Windows красная 30 лет назад была DOS велосипедом, поэтому в ней до сих пор используется MAX_PATH велосипедная цепь, причем всего 260 символов на весь путь сплетенная из бересты. Поэтому при ее использовании нельзя использовать современные ограничения длины пути скорости, а приходится пользоваться тем, что было 30 лет назад, иначе приложения, написанные копипастом из древней документации MSDN, сломаются цель порвется. Зато вы можете использовать иероглифы и эмодзи в именах использовать встроенные сервоприводы для подпрыгивания на месте под музыку, ведь это гораздо веселее, чем давать файлам и папкам имена произвольной длины передвигаться быстрее пешехода. Если использовать UNC-пути запрячь перед машиной лошадь, то ограничения немного снимаются, но не полностью. И мало программ, которые их используют почти нет дорог, не разрешено запрягать лошадь перед машиной.

Мораль: legacy код и документацию нужно рефакторить хотя бы раз в 10 лет при проектировании машин не нужно использовать велосипедную цепь в качестве основы.

У нас в 99% юзеры и знать не знают, какой длины будет получившиеся имена файлов, потому что они генерируются автоматом либо вордом по первому абзацу, либо это сохраняемая из интернета страница с охренительно длинным заголовком, сгенерированным, между прочим, вами, господа программисты :)

Спасибо за статью, тоже есть проблемы с этим. А с чем связано то, что поддержка длинных путей не включена по умолчанию в современных win10 и прочих? Я не вижу проблем с совместимостью, кроме того что станет работать то, что раньше не работало.
Сейчас дела обстоят так, что файловая система и некоторый софт поддерживают очень длинные имена и создают такие, а другой софт не поддерживает и не может к ним обратиться.
В файловой системе NTFS возможны циклы и они там есть (см. структуру папки App Data). Если какая-то программа хочет получить список всех файлов в папке с циклами, она в этом случае быстро упрётся в MAX_PATH, а если его увеличить, то программа либо вылетит из-за кривой реализации перечисления, либо съест всю имеющуюся оперативную память.
Вообще в доках MSDN можно найти очень много кода с такими объявлениями:
TCHAR szDir[MAX_PATH];

(Строка, с максимальным количеством символов в 260)

И если какая-то программа будет написана копипастом оттуда… Она, скорее всего, сломается и упадёт, а может ещё перед этим натворить делов. Так что лучше с включением длинных путей поаккуратнее быть.

Не внезапно. Даже гуглить не обязательно. Если откроете 3ю ссылку из списка в конце моей статьи, то там будет упоминание этой либы.
Даже если проблему решал кто-то другой, ничто не мешает подойти к ее решению с другой стороны.

Зачем быть таким категоричным.
AlphaFS знаю и использую, в ней даже есть изменения после моей дискуссии с разработчиком.
Но:
1. Использование сторонних библиотек в инфраструктуре например стороннего заказчика не всегда возможно.
2. AlphaFS не универсальна — она до сих пор не позволяет сделать аналог Get-ChildItem -Directory -Recurse с захватом ошибок через catch.

У меня недавно был косяк в cmake скрипте. Вместо сборки third party я насоздавал рекурсивно очень много вложенных каталогов. Так вот, ключи в реестре не помогли, total не помог. Проводник вообще крэшился при ручной попытке зайти слишком глубоко. Всякие killcopy тоже не смогли.
Спасла линуксовая консоль в WSL.

А, так вот зачем они эту WSL сделали?! :)
robocopy хорошо помогает, как уже сказано выше.
Делаешь /MIR пустой папки в папку с кривулями — и вуаля!
Еще очень хорошо таким образом чистить содержимое папок, содержащих сотни тысяч — миллионы файлов.
Насколько я помню, где то был разбор что включение поддержки в W10 не рабоатет для проводника, поскольку он использует старые WinAPI функции.

Т.е. переходом на W10 у менеджера Васи проблемы не решаются.

В опросе отметил "другое", ибо везде использую Linux. С описываемой проблемой не сталкивался.

Sign up to leave a comment.

Articles

Change theme settings