Изъятие файлов из каталога в условиях параллельного подкладывания туда новых

Самая глупая идея, которая приходит в голову - монтировать к твоему каталогу велосипедную ФС на fuse. Когда файл закрывается клиентом - можно скармливать его демону.

Не уверен, что будет работать, ибо понятия не имею как ведёт себя smb-демон при разрыве соединения с клиентом.

Ещё более глупая идея - пропатчить с той же целью smb ;).

1. сканируем каталог и запоминаем имена файлов и их размер
2. делаем паузу на N минут/секунд
3. снова сканируем каталог и запоминаем имя/размер
4. обрабатываем те файлы, у которых не изменился размер между последними сканированиями
5. переходим к п. 2

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

Смотреть через /proc а не открыт ли файл кладущим процессом?

http://en.wikipedia.org/wiki/File_locking#Linux поможет? :)

посмотри в сторону inotyfywait. Можно заставить демон ожидать события close_write

Пускай "ПО, которое копирует файл", по окончании этого копирования создает какой-то файл, к примеру "bla.flag".

> inotyfywait

inotifywait

Может имеет смысл сравнивать mtime(время модификации) и переносить только если оно больше e.g. 5 минут.

1. Сканируем каталог, находим новый файл.
2. Удаляем файл.
3. Если файл удалился, значит его нужно было копировать.

> Если файл удалился, значит его нужно было копировать.

^-)

Спасибо за проявленный интерес к проблеме!

Отвечаю скопом:

> Самая глупая идея, которая приходит в голову - монтировать к твоему каталогу велосипедную ФС на fuse

Контроля над ФС у меня нет. Окружение - произвольное. Не обязательно даже Линукс, честно говоря.

2Crocodille: собственно, такой подход я описал вторым вариантом. Возможно, но интересны иные варианты.

>http://en.wikipedia.org/wiki/File_locking#Linux поможет? :)

А разве при копировании файлы блокируются? Я не могу делать никаких оберток вокруг это процесса - это полностью вне моего контроля.

> Пускай "ПО, которое копирует файл", по окончании этого копирования создает какой-то файл, к примеру "bla.flag"

Нету никакого "ПО". Есть пользователи, которые копируют файлы "в расшаренную папочку" проводником. В лучшем случае - FAR'ом.

> Может имеет смысл сравнивать mtime(время модификации) и переносить только если оно больше e.g. 5 минут.

Такой подход я описал первым вариантом. Возможно, но интересны иные варианты. Причины - опять же, см. выше.

> Если файл удалился, значит его нужно было копировать

Хм, возможно. Хотя, конечно, затраты на ненужное копирование (перед проверкой удалением надо ведь скопировать файл) могут быть не совсем пренебрежимыми (типичный размер файлов - несколько десятков мегабайт, самих файлов - сотни/тысячи в день, пользователи их копируют пачками по несколько сот за раз).

> inotifywait

Ага, это интересно. В случае, когда демон в Линуксе - похоже, то, что надо. Спасибо!

Так делать нельзя. Делать надо два каталога в один пишем (dir1), как только запись закончена делаем move (атомарная операция) в другой каталог (dir2). Состояние dir2 отслеживаем одним из доступных механизмнов ядра (dnotify/inotify).

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

> Делать надо два каталога в один пишем (dir1), как только запись закончена делаем move

Ну, собственно вопрос как раз и есть в том, как определять, что запись закончена. А move или copy - не важно, т.к. после окончания записи с файлом может работать только демон. Хотя, для исключения человеческого фактора можно подстраховаться.

>учитывая что писать будут люди, искплорером или фаром

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

Причём, чем раньше это сделаешь, тем меньше потом выгребать проблем придётся. Ручная работа с не-личными файлами - зло.

В твоем случае (SMB share) кроссплатформенным решением будет 
смотреть вывод smbstatus

Locked files:
Pid    DenyMode   Access      R/W        Oplock           Name
--------------------------------------------------------------
26166  DENY_NONE  0x2019f     RDWR       NONE             /export/home/dir/file   Wed Dec 24 09:38:47 2008
26166  DENY_NONE  0x20089     RDONLY     EXCLUSIVE+BATCH  /export/home/dir/   Wed Dec 24 09:38:43 2008

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

>ты словил это событие и начал с ним работать,

файл уже в перенесен в др. директорию

>а тут его опять открывают и начинают дописывать в конец.

Это уже новый файл

З.Ы. Я так думаю

> Так избавь их от этой привычки. Напиши им скриптец "послать всё", который делает всё правильно

Сложно получается. Дополнительную программу надо ставить пользователям, поддерживать (поскольку одновременно в один каталог могут сбрасывать файлы куча людей, то если уж делать дополнительную программную прослойку, то не через каталог, а слать файлы демону напрямую), обучать пользователей, уговаривать, что в этой программе нет ничего сложного и страшного - в общем, много проблем. Плюс, теоретически, надо согласовывать установку дополнительного ПО с техотделом.

А вот сказать: вот вам каталог, вы туда можете скидывать файлы для обработки - это значительно проще (практика показывает). Хотя опасность того, что кто-то решит, что скинул не то и начнет удалять/перезаписывать, она есть. Но (опять же, из практики) гораздо проще запугать пользователя опасностями, поджидающими его в этом особом каталоге, чем уговорить пользоваться дополнительной программой. Честное слово, даже программой с двумя кнопками и элементом выбора каталога пользоваться не хотят.

Она(функция move,rename) не работает при перемещении между разными точками монтирования.

Еще вариант в голову пришёл.
Можно разрешить аплоад на сервер, но запретить удаление.
В это й ситуации пользователь не сможет ни дописать, ни перезаписать файл. Поэтому, при CLOSE_WRITE у тебя будет гарантировано цельный файл и никто его не будет дописывать.
Такое можно сделать на фтп-сервере, может у самбы что-то похожее есть. Или вообще замени самбу на фтп.

как уже было сказано - надо парсить работу протокола smb
я делал нечто подобное через парсинг лога vsftpd - все видно по протоколу ftp что пришло и ушло
думается smb протокол тоже логируется и это можно использовать

> А вот сказать: вот вам каталог, вы туда можете скидывать файлы для обработки - это значительно проще (практика показывает). Хотя опасность того, что кто-то решит, что скинул не то и начнет удалять/перезаписывать, она есть.

пусть по загрузке файла пользователь открывает веб-страницу,
со списком загруженных (этим пользователем) файлов и жмет кнопку
"вот этот файл обработать"

чай браузером сейчас все пользоваться умеют

* по окончании загрузки

>>учитывая что писать будут люди, искплорером или фаром

> Так избавь их от этой привычки. Напиши им скриптец "послать всё", который делает всё правильно.

это не решение проблемы а фашизм

> пусть по загрузке файла пользователь открывает веб-страницу, со списком загруженных (этим пользователем) файлов и жмет кнопку "вот этот файл обработать"

Во-первых, этого никто делать не будет. Точно говорю. Этим девочкам проще угробить пару недель/месяцев на ручную обработку, чем зайти на какую-то страницу и что-то там сделать.

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

ну тогда да

>сказать: вот вам каталог ... это значительно проще

В начале. Экономия на аккуратном дизайне окупается редко. Хотя, если беспорядок в поддерживаемых системах приемлем -- жить можно.

>программой с двумя кнопками и элементом выбора каталога пользоваться не хотят

А что такое "файловый менеджер", если не программа выбора каталога с кучей кнопок?

>это не решение проблемы а фашизм

Это не фашизм, а опыт. Вот понадобилась такая блажь -- порядок в системе. Так вот, изменить "потом" намного труднее. 2 года долбимся.

> А что такое "файловый менеджер"

Это такое беленькое окошечко, куда девочки перетаскивают мышечкой иконочки. Наверху написано "Проводник". Вызывается из меню "Пуск". И служит для работы с любыми файликами и папочками, не только с какими-то определенными.

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

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

>проста и прозрачна. Никаких новых знаний, инструментов и навыков

А названия каталогов, и что куда нужно перетаскивать, впитывается с молоком матери? Таким образом ты "прошиваешь" процессы обработки в прелестные головки голубоглазых блондинок. Что, в общем то не плохо, до тех пор, пока тебе не предъявят какое-нибудь новое требование, типа не хранить конфиденциальные данные в нешифрованном виде. В этот момент уже твои глаза вдруг наполняются обидой и т.п.

>проектирование проводник-подобного интерфейса

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

Впрочем, уговаривать не буду -- каждый сам себе злобный кузнец.

> А названия каталогов, и что куда нужно перетаскивать, впитывается с молоком матери?

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

> до тех пор, пока тебе не предъявят какое-нибудь новое требование

В данном случае задача компактна и однозначно интерпретируема. Есть поток файлов, поступающих через исполнителей, файлы надо обработать. Все.

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

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

> Мне пока пришло в голову смотреть на временную метку модификации файла и забирать только файлы, которые не менялись в последние N секунд/минут.

Смотри размер файла. Если не менялся за какое-то время (и если доступ к шаре по локалке, а не по дайлапу) - можешь пытаться забрать (move) его к себе на обработку. Если можешь дополнительно проверить список открытых файлов (как писали выше) - то вообще замечательно.

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

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