информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медСетевые кракеры и правда о деле ЛевинаЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Модель надежности отказоустойчивой... 
 Apple случайно превратила FaceTime... 
 С наступающим 
 Неприятная уязвимость в SQLite... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Скрипт сам находит файл на фтп, тоесть он запущен постоянно 22.11.06 15:08  Число просмотров: 3710
Автор: DamNet [Bugtraq.ru Team] <Denis Amelin> Статус: Elderman
<"чистая" ссылка>
по поводу sleep синтаксис если можно по подробнее.
<programming>
А есть ли у нас гуру по VBS? 22.11.06 13:15  
Автор: DamNet [Bugtraq.ru Team] <Denis Amelin> Статус: Elderman
<"чистая" ссылка>
Есть некий скриптик, занимается тем, что берет с ФТП-шки файл, пихает его в локальную папку. берет файлик как только он появляется собственно на самой ФТП. раньше инкаких собсно проблем не возникало, но вот есть подозоение, что всвязи с тем что размер файлика увеличился, скрипт начинает забирать его раньше чем он туда ложится, и соответственно получается что файл битый.

Собсно вопрос, как можно увеличить ожидание с момента обнаружения файла до момента начала скачивания оного. заранее спасибо.
)
А написать прогу которая каждый отрезок времени сливает... 16.12.06 17:33  
Автор: MadBinom Статус: Незарегистрированный пользователь
<"чистая" ссылка>
А написать прогу которая каждый отрезок времени сливает файл, если на него есть полный(неконкуретный в смысле) доступ?
Предлагаю 22.11.06 14:13  
Автор: whiletrue <Роман> Статус: Elderman
Отредактировано 22.11.06 14:25  Количество правок: 2
<"чистая" ссылка>
Сделать проверку 2 раза:

При первой проверке запоминать размер, но файл не начинать читать
При второй проверке - если есть запомненный файл и текущий размер на ФТП совпадает с запомненным - начинать читать.

P.S А вообще можно и размер не проверять - просто читать только со второго раза... если промежуток между проверками достаточно большой
Задача не тривиальная. Сталкивался с подобными вещами -... 22.11.06 16:03  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 22.11.06 16:04  Количество правок: 1
<"чистая" ссылка>
> Сделать проверку 2 раза:

Задача не тривиальная. Сталкивался с подобными вещами - где-то надо было на файлообменнике что-то с файлом делать, как его скинут. Причем не важно ФТП или МСН.

> При первой проверке запоминать размер, но файл не начинать
> читать
> При второй проверке - если есть запомненный файл и текущий
> размер на ФТП совпадает с запомненным - начинать читать.

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

> P.S А вообще можно и размер не проверять - просто читать
> только со второго раза... если промежуток между проверками
> достаточно большой

В идеале нужен сигнал скрипту, как только заливка файла завершается. ФТП никакие сигналы слать не умеет.
Один из неплохих выходов - написать свою прогу copy/move, только чтоб она пыталась открыть файл на изменение а не "readonly". В случае удачного открытия - делаем то что нужно (копируем/с_удалением), иначе откладываем до следующей попытки. В предположении того, что ФТПсервер или любая другая выкладывающая файл прога открывает файл тоже для записи, но не в режиме SHARED копирующей проге в доступе с режимом на изменение будет отказано, пока файл не закроется.

В принципе может помочь и небольшая задержка в этом конкретном случае. Подтверждением того, что линия скоростная, без задержек и размер маленький может быто то, что подобные баги случаются довольно редко.
Извините, за возможно идиотский постинг. Но может... 23.11.06 07:26  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
> > Сделать проверку 2 раза:
>
> Задача не тривиальная. Сталкивался с подобными вещами -
> где-то надо было на файлообменнике что-то с файлом делать,
> как его скинут. Причем не важно ФТП или МСН.
>
> > При первой проверке запоминать размер, но файл не
> начинать
> > читать
> > При второй проверке - если есть запомненный файл и
> текущий
> > размер на ФТП совпадает с запомненным - начинать
> читать.
>
> Не тривиальность в том, что скорость передачи по сетям
> может быть мала, а размер большой, плюс задержки в сети.
> Короче какие большие задержки в скрипте не делать - может
> мало оказаться, с другой стороны хочется чтоб время реакции
> было минимально.
>
> > P.S А вообще можно и размер не проверять - просто
> читать
> > только со второго раза... если промежуток между
> проверками
> > достаточно большой
>
> В идеале нужен сигнал скрипту, как только заливка файла
> завершается. ФТП никакие сигналы слать не умеет.
> Один из неплохих выходов - написать свою прогу copy/move,
> только чтоб она пыталась открыть файл на изменение а не
> "readonly". В случае удачного открытия - делаем то что
> нужно (копируем/с_удалением), иначе откладываем до
> следующей попытки. В предположении того, что ФТПсервер или
> любая другая выкладывающая файл прога открывает файл тоже
> для записи, но не в режиме SHARED копирующей проге в
> доступе с режимом на изменение будет отказано, пока файл не
> закроется.
>
> В принципе может помочь и небольшая задержка в этом
> конкретном случае. Подтверждением того, что линия
> скоростная, без задержек и размер маленький может быто то,
> что подобные баги случаются довольно редко.
Извините, за возможно идиотский постинг. Но может пересмотреть бизнес правила?
Например, все промышленные протоколы такого рода (Блюмберг, Рейтерс, Томсон) требуют передачи как минимум двух файлов. Одном манюсенький (типа дескрипшн) . Он посылается в последнюю очередь. Второй(ые) - сосно файл(ы).
Без проблем можно рассмотреть, но к сожалению я например... 23.11.06 13:17  
Автор: DamNet [Bugtraq.ru Team] <Denis Amelin> Статус: Elderman
<"чистая" ссылка>
> > > Сделать проверку 2 раза:
> >
> > Задача не тривиальная. Сталкивался с подобными вещами
> -
> > где-то надо было на файлообменнике что-то с файлом
> делать,
> > как его скинут. Причем не важно ФТП или МСН.
> >
> > > При первой проверке запоминать размер, но файл не
> > начинать
> > > читать
> > > При второй проверке - если есть запомненный файл
> и
> > текущий
> > > размер на ФТП совпадает с запомненным - начинать
> > читать.
> >
> > Не тривиальность в том, что скорость передачи по сетям
> > может быть мала, а размер большой, плюс задержки в
> сети.
> > Короче какие большие задержки в скрипте не делать -
> может
> > мало оказаться, с другой стороны хочется чтоб время
> реакции
> > было минимально.
> >
> > > P.S А вообще можно и размер не проверять - просто
> > читать
> > > только со второго раза... если промежуток между
> > проверками
> > > достаточно большой
> >
> > В идеале нужен сигнал скрипту, как только заливка
> файла
> > завершается. ФТП никакие сигналы слать не умеет.
> > Один из неплохих выходов - написать свою прогу
> copy/move,
> > только чтоб она пыталась открыть файл на изменение а
> не
> > "readonly". В случае удачного открытия - делаем то что
> > нужно (копируем/с_удалением), иначе откладываем до
> > следующей попытки. В предположении того, что ФТПсервер
> или
> > любая другая выкладывающая файл прога открывает файл
> тоже
> > для записи, но не в режиме SHARED копирующей проге в
> > доступе с режимом на изменение будет отказано, пока
> файл не
> > закроется.
> >
> > В принципе может помочь и небольшая задержка в этом
> > конкретном случае. Подтверждением того, что линия
> > скоростная, без задержек и размер маленький может быто
> то,
> > что подобные баги случаются довольно редко.
> Извините, за возможно идиотский постинг. Но может
> пересмотреть бизнес правила?

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

Условия примерно такие: есть распределенная СУБД, Пусть будет главная А и переферийная Б,
каждые N минут Б создает файл с выгрузкой. Задача в общем-то простая, как можно быстрее загрузить этот файл в базу А, и выгрузить из А ответ.
Решение задачи усложняется тем, что канал между А и Б очень и очень нестабильный, и пинг состовляет порядка 800-1000 мс
При этом конечно было бы не плохо, что бы без стороннего софта, встроенными средствами MS.

> Например, все промышленные протоколы такого рода (Блюмберг,
> Рейтерс, Томсон) требуют передачи как минимум двух файлов.
> Одном манюсенький (типа дескрипшн) . Он посылается в
> последнюю очередь. Второй(ые) - сосно файл(ы).

Действительно интересное решение и имеет право на жизнь )
Если это выгрузка из СУБД, так может в СУБД предусмотрен механизм репликации? 23.11.06 14:43  
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
<"чистая" ссылка>
в СУБД нет встроенного репликатора отвечающего задачам. 23.11.06 18:47  
Автор: DamNet [Bugtraq.ru Team] <Denis Amelin> Статус: Elderman
<"чистая" ссылка>
Тоже одно из неплохих решений. Только не бизнес правила, а... 23.11.06 10:37  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 23.11.06 10:38  Количество правок: 1
<"чистая" ссылка>
> Извините, за возможно идиотский постинг. Но может
> пересмотреть бизнес правила?

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

> Например, все промышленные протоколы такого рода (Блюмберг,
> Рейтерс, Томсон) требуют передачи как минимум двух файлов.
> Одном манюсенький (типа дескрипшн) . Он посылается в
> последнюю очередь. Второй(ые) - сосно файл(ы).

Можно упростить, просто пустой файл слать или с контрольной суммой первого, например. Имя такое же, а к расширению приписать что-нибудь специфичное. Например шлем файл ahtung.doc, а затем вдогонку ahtung.doc.sync. Скрипт сканирует только на *.sync. Естествено расширение надо выбирать поэкзотичнее, чтоб не пересеклось с посылаемыми.
В случае автоматической передачи - проблем нет. Минус такой схемы, если посылают вручную - надо еще какой-то файл создавать и его тоже посылать.
вариант 23.11.06 13:01  
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка>
посылать файл юзером А, с umask 027. после заливки делать ему chmod
забирать другим юзером - Б. соответственно юзер Б не сможет прочитать файл пока ему не дадут прав на него. А это естетственно произойдёт только после заливки. Единственно, надо в скрипте прописать обработчик отлупа по Access Denied, чтобы он не дропал этот файл с воплями "Не могу!!!" а культурно ждал и ретраил через 10-15 мин.
Эта ветка - ну прям генератор идей. И это предложение тоже... 23.11.06 14:29  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> посылать файл юзером А, с umask 027. после заливки делать
> ему chmod

Эта ветка - ну прям генератор идей. И это предложение тоже классное - быстрее, чем передача синхронизационного файла, например. Только вот у человека беда - Винда, у которой почти не chmod'а и файлы льются по ФТП, через который чмодить проблематично. А для юниксистов с NFS вполне подойдет.
фтп чмодить умеет. Умеет ли это СУБД которая выкладывает -... 23.11.06 15:01  
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка>
фтп чмодить умеет. Умеет ли это СУБД которая выкладывает - вопрос.
FTP>chmod -- Invalid command. 23.11.06 16:02  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
Нормальные FTP-клиенты и серверы это умеют 23.11.06 16:16  
Автор: :-) <:-)> Статус: Elderman
<"чистая" ссылка>
$ ftp
ftp> help chmod
chmod           change file permissions of remote file
ftp>

---
Какой смысл делать chmod, если файловая система на сервер,... 23.11.06 16:34  
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
<"чистая" ссылка>
Какой смысл делать chmod, если файловая система на сервер, например, ФАТ или НТФС?
(Это я не к тому, что фтп-клиент не должен уметь делать чмод, а к тому, что даже если он умеет, то не всегда сможет)
Варианты решения: 23.11.06 17:19  
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка>
Варианты решения:
1. установить фтп на каком-нибудь юниксе.
2. использовать что-то вроде set_permissions.asp на том же иисе, если СУБД умеет это делать.
Вариант 3:
наконец настроить фтп-репликацию средствами субд :)) MSSQL умеет это по-моему ещё с 7-й версии. Хотя и кривовато, как всегда.
Или еще проще 23.11.06 17:55  
Автор: :-) <:-)> Статус: Elderman
<"чистая" ссылка>
Заливать файл под именем "filename.NOT_FINISHED", а после заливки переименовывать его, убирая из имени суффикс ".NOT_FINISHED".
Только не говорите, что ущербные виндовые ФТП-серверы не поддерживают переименоване файлов =)
Согласен 23.11.06 19:34  
Автор: Ustin <Ustin> Статус: Elderman
<"чистая" ссылка>
> Заливать файл под именем "filename.NOT_FINISHED", а после
> заливки переименовывать его, убирая из имени суффикс
> ".NOT_FINISHED".
> Только не говорите, что ущербные виндовые ФТП-серверы не
> поддерживают переименоване файлов =)
Собсно была центральная БД, к которой по FTP ходила куча клиентов и забирала достаточно большой файл синхрониции.
Обмен клиентов с центром был реализован примерно так: когда файл синхронизации недолит или до его модификации остаётся менее 30 секунд, рядом начинает валяться файл-флаг "не брать", удаляющийся при завершении обновления. Далее в течение таймаута (в 2 минуты, например), фаил не модифицируется.
Таймауты подобраны экспериментально, клиенты ходят с наладонников по GPRS, схема работает до сих пор.
Запускать скрипт позже, когда файл уже точно весь на ФТП? Вставить sleep? 22.11.06 13:45  
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
<"чистая" ссылка>
Написал сюда, шоб некоторое время повисело. 16.01.07 17:34  
Автор: Fighter <Vladimir> Статус: Elderman
<"чистая" ссылка>
Сдется мне, что этот гребаный бот с дыркой. Может попробуем найти с-суку?
1  |  2 >>  »  






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2019 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach