Всем привет!
Ситуация следующая: есть очень сильно разветвленное дерево папок, и в этих папках лежат файлы. Нужен быстрый способ поиска файла по корневому каталогу и имени.

средствами v7.7?

dir /s корень\файл

(1) средствами 7.7 быстро врятли получится, нужно чтото иное, возможно WMI, но мне его юзать не приходилось еще пока поэтому не уверен

(2) это не быстрый способ, виндовозный поиск работает быстрее чем dir

(4) виндовский поиск индекс использует

(5)молодец, садись 5.
По проблеме может кто помочь, делал кто-то подобное и если делал то с помощью чего?

(0) и как часто предполагается проводить такую операцию, что она упирается в скорость?

(0) загнать его в ТЗ

(6) А что тебе не нравится? Хочешь скорости - индексируй.

СписокXMLФайл.УдалитьВсе();
   
   FSO    = СоздатьОбъект("Scripting.FileSystemObject");
   ScrCtr = СоздатьОбъект("MSScriptControl.ScriptControl");
   ScrCtr.language = "javascript";
   
   Плохо = 0;
   Попытка
       Folder = FSO.GetFolder(НачалоПути+Строка(НомерМаршрута)+СерединаПути);
   Исключение
       Сообщить("Проблема с файлами... "+ОписаниеОшибки());
       Плохо = 1;
   КонецПопытки;
   Если Плохо = 1 Тогда
       СтатусВозврата(0);
       Возврат;
   КонецЕсли;
   
   ScrCtr.AddObject("Подпапки",Folder.SubFolders);
   Подпапки=ScrCtr.Eval("new Enumerator(Подпапки)");
   Пока Подпапки.atEnd(0)=0 Цикл
       ИмяКаталога = Подпапки.item(0).Name;
       
       Если Лев(ИмяКаталога,12) = ОкончаниеПути+Формат(ДатаМаршрута,"Д ГГГГММДД") Тогда
           //Сообщить("Папка = " + ИмяКаталога);
           ВремИмяФайла = НачалоПути+Строка(НомерМаршрута)+СерединаПути+ИмяКаталога+"\"+ШаблонИмени;
           Если FSO.FileExists(ВремИмяФайла)<>0 Тогда
               СписокXMLФайл.ДобавитьЗначение(ВремИмяФайла);
           КонецЕсли;
       КонецЕсли;
       
       Подпапки.moveNext(0);
   КонецЦикла;

(10) чем это быстрее ФС.НайтиФайл ? и где рекурсия ?

http://www.voidtools.com/download.php

(11) я привел пример, а не готовое решение
т.е. задал "вектор"

(13) чем это отличается от ФС.НайтиФайл ?

(14) ИМХО работает быстрее

(10) покурил разные статейки в интернете и где-то вычитал что при поиске файлов, если налагаются условия доп условия, то WMI отрабатывает быстрее чем FSO, посему написал такую белеберду:
               ScrCrl = СоздатьОбъект("MSScriptControl.ScriptControl");

               ScrCrl.Language = "javascript";

               Locator = СоздатьОбъект("WbemScripting.SWbemLocator");

               Service = Locator.ConnectServer();

               Service.Security_.ImpersonationLevel=3;

               NP = Service.ExecQuery("

               |SELECT Name

               |FROM CIM_DataFile

               |WHERE Drive = 'Q:' AND Path LIKE '\\%' AND FileName = '"+СокрЛП(ИмяФайла)+"'");

               ScrCrl.AddObject("NP",NP);

               NP = ScrCrl.Eval("new Enumerator (NP)");          

               Пока NP.atEnd(0) = 0 Цикл

                               Сообщить(NP.item(0).name);

                               NP.moveNext(0);

               КонецЦикла;
Но все равно ищет медленно, может кто подскажет как ускорить??

(16) не быстрее

особо лайк в свете сабжа радует

(18) а как тут без лайка, вообщем народ я уже 2-ой день голову себе ломаю в одиночестве, посоветоваться не с кем, так что выручайте

Файлы в каталог пишешь из 1ски или сторонние программы

Drive = 'Q:' AND FileName = '"+СокрЛП(ИмяФайла)+"'"

вернее как то так

Точка=Найти(ИмяФайла,".");
Имя=Лев(ИмяФайла,Точка-1);
Расширение=Прав(ИмяФайла,Точка+1);
...
Drive = 'Q:' AND FileName = '"+Имя+"' and extension='"+Расширение+"'"

ну или как то вернее найти последнюю точку, т.е. имя и расширение

(20) нет не пишу их, это сканы оригиналов доков, я хочу их прицепить к докам базы
(22) в таком случае он будет искать только в корне, а мне нужен поиск во всем дереве каталогов(дерево состоит из 2500 папок и 9000+ файлов), и расширение файла не известно, это может быть .jpg, .pdf или tiff

(24) тебя вопрос в (7) ни на какие мысли не натолкнул?

(25)натолкнул, но к примеру надо в налоговую отправить 500 сканов ориганалов доков, и поиск тогда займет больше 4 часов

(26) Реорганизуй хранилище так, чтобы ничего не нужно было искать - на это он должен был на толкнуть. То есть нормальная структура хранения с сохранением в 1С относительного пути к каждому изображению. Или вообще БД.

(24) Вы это кому сказали ?

(27) понятно что все будет реорганизовано, меня интересует именно быстрый поиск
(28) -> (0)

(29) хреново Вы понимаете, см внимательно (22)

(30) разницы по времени никакой, а так да невнимателен, спасибо

На самом деле вам нада упорядочить каталог. За дерево с 2к папок нада руки в двери ставить. Тогда и вопрос поиска решится сам собой.

(32)реструктуризацию проведу, в этом мне кстати и поможет мой поиск. Просто хотелось найти самый быстрый вариант поиска(изучать все технологии нет времени, потому и спрашивал мало ли есть кто опытный).
При одинаковых условиях:
- обычный виндовозный поиск справляется за чуть больше чем 20 сек (но не знаю по какому принципу он работает и как его к 1С прикрутить)
- WMI запрос и команда DIR примерно за 40 сек
- FSO через обзор папок с рекурсией самый медленный

в документ разово запихай путь к его сканкопии и забуть про скорость поиска. наверника есть какаято структура этого каталога и можно искать не во всех нацати папках а только в малой их части

можеш сделать маленькую базку в которую запихать все папки и имена и ее в 1 индекснуть оброботать как надо

(33) а через ФС.НайтиПервыйФайл засекал ?
:)

скопировать директорию и выкинуть оброботкой все файлы в корень этой дириктори.

(36) через ФС не смог реализовать, атрибутыФайла() не возвращает имя каталога (((, не знаю почему, платформа наверное глючит

(33) для реструктуризации поиск абсолютно не нужен

>> обычный виндовозный поиск
Какая версия windows?
Обычный не должен сильно отличаться от того же dir.
А вот если windows search задействован, то да (но из коробки он только в младших версиях windows включён).

(40) server 2003, конечно я search имел ввиду

(39)ну не руками же структурировать, а так заложу нормальную  структуру дерева в обработку и распихаю по ней файлы

(41)
На 2003 search отдельно ставится

Помнится, в свое время в роадмапе висты была идея о встраивании службы индексирования и поиска напрямую в NTFS. Чтобы файлы можно было выбирать sql-запросами.. Что-то не взлетело :(

(44) чем тебе в (16) не SQL запрос

(44)
Не напрямую в NTFS, конечно:
http://msdn.microsoft.com/en-us/library/windows/desktop/ff684395(v=vs.85).aspx

(46) Изначально речь шла именно о встроенной в ntfs поддержке индексирования, а не о дополнительной службе поверх ФС. А вообще, идея неплохая была.. Реляционная надстройка поверх иерархической ФС для быстрого доступа, с сохранением возможности иерархического доступа, но без обязательного требования иерархичности. Грубо говоря, предполагалось, что файл сохранялся "куда-то на диск", а ключом к открытию файла становился не иерархический путь, а набор критериев базы данных, то есть, условие WHERE в sql-запросе, по сути. В качестве критериев могли выступать как имя файла (в том числе и пословно со склонениями), так и ключевые слова содержимого, метаданные и т.п. - через соответствующие библиотеки парсинга. При сохранении файла на ФС его индексирование происходило сразу же, а не по расписанию.