Как оптимизировать сбор длины пути всех файлов на ПК?

Доброго времени суток.
Появилась у меня мысль - проверить длину пути ко всем файлам на ПК ( по стандарту NTFS (255 символов ограничение)).
Задача проста и выполнима...Если бы не одно но -
Наткнувшись на пост от уважаемого UI...
Понял что у моего кода скорость работы - велика .
Вот и вопрос - как оптимизировать сбор длины пути всех файлов на ПК? (возможно не используя FindFirstFile?)
Хотелось бы совет от старших товарищей

0

Сообщение от Ddv122 скорость работы - велика

а надо еще больше?

0

Ddv122, чисто ради хохмы, попробуйте стандартным виндовым поиском поискать какой-нибудь файл среди

Сообщение от Ddv122 всех файлов на ПК

. или строку какую-нибудь во всех файлах. Сильно ваш код будет уступать ему? В процентном соотношении.
FindFirstFile это винапишная функция - вряд ли есть что-то быстрее.
Если только Убежденный вам посоветует какой-нибудь хитрый ход.

1

Сообщение от SatanaXIII попробуйте стандартным виндовым поиском поискать

известно, что TotalCommander как-то умудряется делать это в разы быстрее

0

Сообщение от AntonChik известно, что TotalCommander как-то умудряется делать это в разы быстрее

О, а я не знал.
Значит есть куда стремиться.

0

Сообщение от SatanaXIII чисто ради хохмы, попробуйте стандартным виндовым поиском поискать

Если фоновое индексирование не выключено, будет много быстрее.

Сообщение от AntonChik известно, что TotalCommander как-то умудряется делать это в разы быстрее

Возможно вот так:

http://msdn.microsoft.com/en-u... 85%29.aspx

1

0

Не много подумав и почитав - мне поможет только одно - сканирование таблицы распределения файлов (MFT) (актуально для NTFS )
Но наверно оно того не стоит

0

Из чистого любопытства - наверно нет. И откуда вообще появилась такая идея? Зачем нужны длины пути, да еще и не просто так - а всех файлов?

0

BRcr,



ну и цитата

Распределение дискового пространства тома NTFS может быть неправильно определено по одной из следующих причин: • Размер кластера тома NTFS слишком велик для среднего размера хранящихся файлов. • Атрибуты файлов или разрешения NTFS препятствуют отображению файлов и папок или доступу к ним при использовании проводника Microsoft Windows или командной строки Windows. • Путь к папке превышает 255 знаков. • Папки или файлы имеют неправильные или зарезервированные имена. • Метафайлы NTFS (такие как основная таблица файлов [MFT]) увеличились в объеме и не могут быть освобождены. • Файлы или папки содержат альтернативные потоки данных. • Повреждение NTFS является причиной определения свободного пространства как используемого в Windows. • Другие возможности NTFS являются причиной неправильного выделения пространства под файлы.

0

Ddv122, не знаю, о каком таком ограничении в 255 символов
идет речь, но система прекрасно уживается с намного более длинными путями:

Naming Files, Paths, and Namespaces
http://msdn.microsoft.com/en-u... 85%29.aspx

Maximum Path Length Limitation The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters.

2

Сообщение от Убежденный не знаю, о каком таком ограничении в 255 символов идет речь

На заре становления пользовательских операционных систем было такое легендарное "Соглашение 8.3" об именовании файлов, которое гласило, что имена файлов не должны превышать восемь символов. Именно оттуда растут корни, многими ныне считаемыми за глюки файловой системы, преобразования длинных имен файлов к виду, что название начинается с тильды, а длина урезается соответственно до семи символов.
В этом же соглашении так же принимались и многие, теперь считающиеся за норму, правила, типа что файл должен иметь расширение, отделяемое непременно именно точкой, и что оно должно иметь ровно три символа; что имя файла не должно начинаться с цифры, а только с буквы или нескольких спецсимволов; что имя файла наоборот не должно содержать другие некоторые спецсимволы; и так далее.
Имя файла-то именем файла, а ведь есть еще и путь к файлу, который предусмотрительно сделали побольше. Отсюда взялось

Сообщение от Ddv122 ограничение 255 (259) символов

Путь к файлу от корня диска мог содержать максимум 255 (считалось, что хватит) символов (плюс 256-ой - ноль на конце), а сам диск, символьное его отображение, хранилось отдельно и не входило в общий путь к файлу. По этому суммарная длина строки, содержащей путь к файлу и именование диска, на котором этот файл располагается, могла составлять 259 (3 + 255 + 1) символов.
Примечательно то, возвращаясь к тому, откуда взялось ограничение на восемь символов в имени файла, что не голый путь, а именно путь вместе с именем файла должен был обязательно уместиться в 255 символов. То есть нельзя было создать из ряда директорий путь в 253 символа и положить в него файл, содержащий хотя бы два буквы в названии (253 + \ + 1), - места оставалось бы только на одну.

P.S. Не знаю правда зачем я распинаюсь, Убежденный вероятно лучше б в три раза все это рассказал.

1

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

1

UI, с помощью сохранения файла со стороннего ПО
Вот путь с 214 символами...

Миниатюры

 

0

UI, меня тоже удивило это намедни. Покопавшись, встретил упоминания о паре способов - через тоталкомандер хитронастроенный и через распаковку образа диска akronis.

0