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

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

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

Как это настроить с DrWeb есть вот тут ftp.drweb.com/pub/drweb/unix/.../doc/drweb-file-servers-500-linux-ru.pdf (глава 7).

Надеюсь, это то, что хотел автор =).

возможно я бы воспольльзовался данным вариантом, но уже создано 2 готовых решения задачи (читайте выше)

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

и DrWeb в данном случае не совсем простой а перенесенный с DrWeb Live CD (таким образом бесплатный)

Как это настроить с DrWeb есть вот тут ftp.drweb.com/pub/drweb/unix/.../doc/drweb-file-servers-500-linux-ru.pdf (глава 7).

Надеюсь, это то, что хотел автор =).

вобщем вот выкладываю 2 продукта 1 основан на InotifyWait другой на Find

inotifywait DrWeb
http://depositfiles.com/files/4e9fooc9a

find DrWeb
http://depositfiles.com/files/m6vvch2t7

попробую сделать с 2 финдами - чтоб наверняка

не надо двух!

find \( -newer file -o -cnewer file \) ....

как раз для этого. -o значит ИЛИ, и в скобках, т.к. приоритет -o меньше -and (-and не пишется, но оно есть)
скобки в слешах, потому-что иначе они не дойдут до find, а обработаются оболочкой

как опробую скажу что получилось

Change: 2010-11-14 15:31:09.000000000 +0300

ну смените на -newer на -cnewer, раз у вас почему-то такая беда.

  File: `image.iso'
  Size: 4428136448    Blocks: 8657150    IO Block: 4096   обычный файл
Device: 804h/2052d    Inode: 173302      Links: 1
Access: (0766/-rwxrw-rw-)  Uid: (65534/  nobody)   Gid: (65534/ nogroup)
Access: 2010-11-16 15:47:49.000000000 +0300
Modify: 2010-08-19 10:28:00.000000000 +0400
Change: 2010-11-14 15:31:09.000000000 +0300

Так это выглядит у мну на ReiserFS - видите 14.11.2010 я его туда скопировал, 16.11.2010 обращался к нему, а дата модификации у него 19.08.2010 - дата его создания на старой ФС

и все файлы так копируются при чом newer file  реагирует именно на дату модификации

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

так может при этом ctime файла изменяется? ИМХО - должна.
у меня меняется (и дата модификации и дата смены статуса)

doc@bx:~$ stat ca.c #новый
  File: `ca.c'
  Size: 425           Blocks: 8          IO Block: 4096   обычный файл
Device: 306h/774d    Inode: 673710      Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/     doc)   Gid: (  100/   users)
Access: 2010-11-05 02:58:08.415126816 +0300
Modify: 2010-11-16 21:42:36.726591011 +0300
Change: 2010-11-16 21:42:36.726591011 +0300
doc@bx:~$ ssh aranei stat ca.c #исходный
  File: `ca.c'
  Size: 425           Blocks: 8          IO Block: 4096   regular file
Device: 308h/776d    Inode: 21540       Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  aranei)   Gid: (  100/   users)
Access: 2010-11-16 21:49:59.416097235 +0300
Modify: 2010-11-05 02:59:03.752136631 +0300
Change: 2010-11-05 02:59:03.752136631 +0300

но это по scp и в Ext4

Есть и "дата создания", как в Windows. Только она у меня не поддерживается.

так что данные все были скопированы с другого винта (NTFS) на текущий (ReiserFS)

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

в /home не вижу смысла потому что сервером как таковым никто не пользуется и единственный пользователь нужен только для ssh входа, у сервака даже монитора клавы и мыши нет))))

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

кому интересно - могу поделиться.............

дык выкладывайте прямо здесь.

PS: я тут подумал, может будет быстрее, если убрать тест -regex ...
и проверять имена вот так:
find \( -iname "*.exe" -o -iname "*.pif" -o -iname "*.что-то-там-ещё" \)

попробуйте поиграться с созданием новой ФС (это по вендоваму "форматирование"), в mkfs.ext4 множество опций для этого. Это если время есть. Насколько я знаю, никто таких тестов не производил. Все форматируют "абы как захотелось маинтейнеру"... А маинтейнеры ставят опции "для всех", потому в таких случаях они не оптимальны. Например, непонятно, зачем в файлопомойке 5% резерва. Жалко. А резерв не нужен, всё равно руту туда нельзя. Резерв нужен на корне, на /var (и то - не для всех), может быть на /tmp. Файлопомойки удобнее всего делать в /home, а тудда заходят лишь пользователи (ну так должно-быть, ИМХО)

производительность действительно шикарная перечисляет папку за несколько секунд

это много или мало?

дык и не должен. зачем проверять уже скопированное?
а... понял. find -newer ищет по дате модификации. есть ещё -anewer и -cnewer. для поиска по дате последнего доступа, и пог дате последнего изменения статуса (создание, смена прав и.т.д)
ну и наконец есть -newerXY

обратите внимание: нужна Linux based FS (ext4 и т.д.) FAT 16 ЕМНИП только 1 дату сохраняет.
И ещё - также важна FS для быстродействия. NTFS - не родная, даже если и работает, то очень медленно. FAT так вообще жутко тормозит

inotifywait с реакцией на close_write + moved_to ловит все скопированные, записанные, перезаписанные, перемещенные, и переименованные файлы