SynFolders - программа для синхронизации папок

[Medic84]

Lance [?]

4) попробовать сделать многопотоковую проверку для большого кол-ва файлов а то время синхронизации так сказать не быстрое(1-й поток чекает с 1-100 файл, 2-й за 101-200 файл... и т.д.)

AutoIt не поддерживает многопоточность. Это минус самого ЯП

А так сейчас пишется v3 полностью с нуля. Пишем только я и Yashied, так что программа должна получиться достойной.

1) возможность постоянной синхронизации или "на лету" (или хотябы возможность ставить менее 1 сек)

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

 

[Lance]

Medic84 [?]

AutoIt не поддерживает многопоточность. Это минус самого ЯП

я думал можно запустить несколько параллельных функций ... на крайняк вызов доп процесса для ускорения

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

о да ... у меня 3000-5000+ файлов которые нужно держать всегда в синхронизации и чем быстрее тем лучше ... и пока только твоя программа справляется... так что это говорит о многом ...

опять же напоминаю что я идиот О_о

 

[kaster]

Lance [?]

я думал можно запустить несколько параллельных функций

нельзя

вызов доп процесса для ускорения

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

 

[Lance]

Kaster [?]

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

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

к счастью особо крутая связь между процессами просто не нужна

 

[kaster]

Lance [?]

мы можем использовать скажем 2 потока ..

потоков нет, и не будет

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

а результат обработки каждой из процессов ты как узнавать будешь?

к счастью особо крутая связь между процессами просто не нужна

крутая не крутая, нужна хоть какая-то. есть некоторые реализации, но это подпадает под определение гемороя.
[?]

я идиот

ок, принял к сведению

 

[Lance]

прошу прощение за сложность моего предложения ... будет время сделаю сам ... тем более что 99% сделано за нас ...

сделать исполняемый файл который будет действовать на основе заданных переменных ... возможно

http://autoit-script.ru/index.php/topic,164.0.html
связать процессы? проброс 1-й переменной может решить данную головоломку

решится сделать это? да не .... лучше считать это идиотизмом...

 

[Yashied]

это ускорит процесс синхронизации в 2 раза...

Наоборот, это затормозит процесс синхронизации в 2 раза. Ради интереса, запусти копироваться два разных файла на одном диске. Теперь четыре файла...



Добавлено:

Сообщение автоматически объединено: 10 Ноя 2011

лог лучше вести только затронутых файлов а то обьём лога поражает

OK

жрёт проца при проверках 2 раза в сек будь здоров... неплохо бы оптимизировать

Оптимизировать как? Любая задержка нехило увеличит время синхронизации. А обращения к диску в любом случае не разгрузит.

 

[Lance]

Yashied, я вас очень уважаю ... всегда вовремя , всегда в тему и чем нибудь тяжёленьким...

Yashied [?]

Наоборот, это затормозит процесс синхронизации в 2 раза. Ради интереса, запусти копироваться два разных файла на одном диске. Теперь четыре файла...

веский аргумент ...
но в моём случае инфа находится на разных носителях ...
а проц горазд обрабатывать большее кол-во функий

тут например можно влепить проверку следующего плана...
1-я миркопрограмма чекает половину 1-й папки
2-я чекает 2-ю половину уже во 2-й папке

в любом случае я заметил что автоит сьедал 1-но ядро... в то время как сата3 хардам был почти курорт
разбивание на разные процессы может это заметно сбалансировать

 

[Yashied]

тут например можно влепить проверку следующего плана...
1-я миркопрограмма чекает половину 1-й папки
2-я чекает 2-ю половину уже во 2-й папке

Этого не будет.

в то время как сата3 хардам был почти курорт

Что SATA1, что SATA3, это не важно, здесь на скорость влияет перемещение головок, а не пропускная способность интерфейса.

 

[Lance]

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

... автоит вообще умеет юзать более 1-го ядра??
просто что делать в случае есть скорость программы упрётся в скорость 1-го ядра??
как это у меня уже было с SynFolders?? или мне повезло что с 4-х ядер он жрал ровно 25% цп?
неужели запуск ещё 1-го процесса не увеличит этот лимит?

 

[Yashied]

Любая однопоточная программа может использовать только одно ядро/процессор. У тебя 4-x ядерный процессор, отсюда и 25%. Для того, чтобы использовать больше одного ядра, нужно создавать дополнительные потоки (в идеале, 4 ядра - 4 потока). Я где-то у нас на форуме приводил пример на PB c 100% загрузкой 4-x ядерного процессора. Но вся сложность здесь заключается в написании оптимального алгоритма для распределения загрузки. В любом случае, в AutoIt, это теряет всякий смысл.

Касательно SynFolders, я конечно могу насоздавать кучу потоков, но алгоритм распределения загрузки получится ооооочень сложный. Поэтому, я этого не буду делать, тем более, что полезность сего действия мне представляется довольно сомнительной.

По поводу разгрузки процессора. Я ради интереса попробывал поставить в цикл Sleep(1), и... так и не дождался окончания синхронизации. Скорость снизилась на несколько порядков. Поэтому, я этого делать тоже не буду. Максимум, что могу сделать, это установить минимальный приоритет для процесса. Этого, в большинстве случаев, будет вполне достаточно.

 

[AZJIO]

Lance
Где требуется работа процессора? На какой обработке? На сколько я знаю при копировании работает хард а не процессор, запрос файлов тоже тормозится на харде, первый раз если получить список 10000 файлов может притормозится до двух секунд, второй запрос 0.3-0.4 сек.
Кстати Sleep(10) и Sleep(1) у меня в цикле отрабатывают с одинаковой скоростью равной Sleep(10).

 

[BaRsupillamy]

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

 

[Medic84]

двусторонняя работает по принципу в какой попке файл создан позже из той и копирует, но мне кажется в этой функции имеется фатальная ошибка.
Лучше ее не использовать и ждать v3.0 (осталось совсем чуть чуть)

 

[BaRsupillamy]

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

 

[Yashied]

я сделал себе две копии программы: одна - Comp-Flash, вторая Flash-Comp... суть ясна из названия... утром одну запускаю вечером другую, дома наоброт...

Так и должно быть.

Направление всегда идет от папки источника (Source) к папке назначения (Destination). Файлы должны удаляться только из Destination!!! При двусторонней синхронизации удалять файлы вообще нельзя, в противном случае, обратная синхронизация (Destination -> Source) будет уже не нужна, т.к. нечего будет синхронизировать.

В v3.0 это все можно будет задать в настройках программы. Еще будет введен режим "Protect", при котором перезаписываемые или удаляемые файлы будут помещаться в корзину (на всякий случай). Ну и еще много всяких плюшек...

 

[madmasles]

Yashied [?]

Еще будет введен режим "Protect", при котором перезаписываемые или удаляемые файлы будут помещаться в корзину (на всякий случай).

Несколько лет назад у меня стояла программа синхронизации (не помню какая), так она файлы сразу не удаляла, а сначала перемещала их во временное хранилище в папку с датой-временем и с сохранением структуры папок, а удаляла их через n (задавалось в настройках) дней. ИМХО, удобно.

 

[BaRsupillamy]

верю в авторов спасибо вам за работу...
ещё хотелки есть... раз есть автосинхронизация при старте, то опционально хотелось бы завершение её после синхронизации... и опционально же поведение по кнопке закрытия - закрыть/свернуть в трей...
спасибо ещё раз очень жду...

 

[Yashied]

Несколько лет назад у меня стояла программа синхронизации (не помню какая), так она файлы сразу не удаляла, а сначала перемещала их во временное хранилище в папку с датой-временем и с сохранением структуры папок, а удаляла их через n (задавалось в настройках) дней. ИМХО, удобно.

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

 

[BaRsupillamy]

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