Re: Détecter un changement dans un répertoire

2023-01-14 Par sujet benoit 
J'utilise lsyncd pour synchroniser des disques ou répertoire.
https://github.com/lsyncd/lsyncd

Ce n'est pas ce que tu recherches, mais le mécanisme de surveillance qu'utilise 
lsyncd, correspond à ta recherche
Il me semble, (à vérifier) que c'est inotify qui est utilisé pour surveiller 
les répertoires et déclencher la synchronisation lors d'un changement.

--
Benoit

--- Original Message ---
Le jeudi 12 janvier 2023 à 15:57, roger.tar...@free.fr  a 
écrit :

> Bonjour,
> et encore bonne année à tous,
>
> Je cherche à surveiller ce qui se passe dans un répertoire.
>
> Il semble exister plusieurs solutions.
> La plus basique consiste à examiner les fichiers déposés, par exemple toutes 
> les minutes (via cron ou avec un programme qui tourne en boucle et se met en 
> pause 1 mn après chaque boucle).
> Je suis plus intéressé par une programmation événementielle où le programme 
> réagit si de nouveaux fichiers sont déposés ou modifiés et détectés par le 
> système.
> Pour faire ça, j'avais examiné inotify mais constaté qu'il y aurait des 
> limitations (de mémoire, par exemple, sur le nombre de fichiers traitables, 
> de inode, etc.).
>
> J'ai repéré notamment : auditd, fswatch, inotify/inotifywait.
>
> Selon vous, pour traiter ce besoin quelle est la solution _FIABLE_ ? (cad qui 
> ne provoque pas d'effets de bord... ou de surprise)
>
> Par ailleurs, pour traiter le cas où des fichiers dépendants les uns des 
> autres sont déposés en vrac, il serait intéressant de pouvoir disposer d'un 
> historique détaillé par fichier, exploitable.
> Je suppose que ça doit être prévu (inotify le fait).
>
> Merci

Re: Détecter un changement dans un répertoire

2023-01-12 Par sujet roger . tarani 



De: "Basile Starynkevitch"  
À: "Liste Debian"  
Envoyé: Jeudi 12 Janvier 2023 20:59:25 
Objet: Re: Détecter un changement dans un répertoire 




On 12/01/2023 20:16, RogerT wrote: 



Pourquoi : pour prendre des décisions de traitement sur évènement « fichier 
créé/modifié/supprimé/etc. ». 

FS : ext4 ou btrfs ou nfs. 




NFS va poser problème. Il est connu et documenté que inotify ne fonctionne pas 
avec NFS, mais avec des systèmes de fichiers locaux et natifs à Linux (dont 
ext4 et btrfs). 

Ok. il suffit de ne pas utiliser NFS. 
Merci. 




BQ_BEGIN


Qté de fichiers : il y a différents cas ; 
1/ surveiller un répertoire où sont déposés des fichiers régulièrement, qui 
vont en être enlevés après traitement ; ici, le nombre de fichiers présents à 
chaque instant sera de l’ordre d’une centaine, voire d’un millier pour 
constituer une file d’attente si le traitement est long et que le flux de dépôt 
de fichiers augmente. 
Là, je crois que inotify et ses dérivés devraient faire l’affaire sans 
atteindre ses limites qui serait de 5E5 fichiers à surveiller. 

BQ_END


A mon avis, c'est faisable programmatiquement (en C++ ou Rust ou C ou Ocaml) 
sur une machine Linux suffisamment puissante (disons 32Go de RAM au moins, et 8 
cœurs). Il faut lire [ https://man7.org/linux/man-pages/man7/inotify.7.html | 
https://man7.org/linux/man-pages/man7/inotify.7.html ] où on peut lire les 
limitations: 



BQ_BEGIN

The inotify API does not report file accesses and modifications
   that may occur because of [ 
https://man7.org/linux/man-pages/man2/mmap.2.html | mmap(2) ] , [ 
https://man7.org/linux/man-pages/man2/msync.2.html | msync(2) ] , and [ 
https://man7.org/linux/man-pages/man2/munmap.2.html | munmap(2) ] . 

BQ_END
Pour 100-1.000 fichiers, aucun souci. 
32 Go/8 coeurs pour 500.000 fichiers ? Tant que ça ? 
L'article que j'ai cité aujoud'hui parle de 1 ko/fichier soit 500 Mo pour 
traiter 5E5 fichiers, ce qui est considérable pour de nombreuses applications. 
Citation : 
Cet article de janvier 2022 apporte des réponses sur la limite et la 
récursivité : 
[ https://www.baeldung.com/linux/inotify-upper-limit-reached | 
https://www.baeldung.com/linux/inotify-upper-limit-reached ] 
« Here, the system allows 524288 (2^19) watches. » 
« Because each watch is a structure, available memory is also a bottleneck for 
using inotify . 
In fact, a watch can take up to 1KB of space. This means a million watches 
could result in 1GB of extra RAM usage. » 


BQ_BEGIN


2/ multiplier les surveillances pour différentes applications ; là je dirais de 
l’ordre de 10E4-10E6 fichiers maximum. Je ne vois pas des milliards de fichiers 
à surveiller. 
Là, inotify devrait encore pouvoir servir si on ne dépasse pas sa fameuse 
limite. 

BQ_END


Mais dix millions de fichiers à surveiller, ça me parait beaucoup. Oui bien 
alors, faire une programmation fine (multi-thread, mulit-processus) qui prendra 
du temps (des mois de travail) et nécessiterait un ordinateur coûteux (serveur 
ou desktop à 10k€, pas un NAS à 500€). 

Erreur de formulation, je voulais dire E4-E6 ou 10^4-10^6 (10.000- 1.000.000). 
Maximum. 
On peut et on doit s'imposer la limite de inotify annoncée de 5E5 (500.000). 





Je ne crois pas à une solution simple, rapide (basée sur inotify ) et 100% 
fiable pour dix millions de fichiers, ou bien alors il faut développer un gros 
logiciel  Le diable est dans les détails. 


Et 100.000-500.000 ? 
Bonne soirée 




Pour ma part, je cherche des partenaires intéressés par le projet logiciel 
libre RefPerSys en [ http://refpersys.org/ | http://refpersys.org/ ] - 
contactez moi alors par courriel (peut-être même au bureau [ 
https://list.cea.fr/ | CEA LIST ] en [ mailto:basile.starynkevi...@cea.fr | 
basile.starynkevi...@cea.fr ] ) 


Bonne soirée. 


-- 
Basile Starynkevitch [ mailto:bas...@starynkevitch.net | 
 ] (only mine opinions / les opinions sont miennes 
uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: Détecter un changement dans un répertoire

2023-01-12 Par sujet Basile Starynkevitch 


On 12/01/2023 20:16, RogerT wrote:
Pourquoi : pour prendre des décisions de traitement sur évènement « 
fichier créé/modifié/supprimé/etc. ».


FS : ext4 ou btrfs ou nfs.



NFS va poser problème. Il est connu et documenté que inotify ne 
fonctionne pas avec NFS, mais avec des systèmes de fichiers locaux et 
natifs à Linux (dont ext4 et btrfs).





Qté de fichiers : il y a différents cas ;
1/ surveiller un répertoire où sont déposés des fichiers 
régulièrement, qui vont en être enlevés après traitement ; ici, le 
nombre de fichiers présents à chaque instant sera de l’ordre d’une 
centaine, voire d’un millier pour constituer une file d’attente si le 
traitement est long et que le flux de dépôt de fichiers augmente.



A mon avis, c'est faisable programmatiquement (en C++ ou Rust ou C ou 
Ocaml) sur une machine Linux suffisamment puissante (disons 32Go de RAM 
au moins, et 8 cœurs). Il faut lire 
https://man7.org/linux/man-pages/man7/inotify.7.html où on peut lire les 
limitations:



The inotify API does not report file accesses and modifications
that may occur because ofmmap(2)  
,msync(2)  
, andmunmap(2)  
.


Là, je crois que inotify et ses dérivés devraient faire l’affaire sans 
atteindre ses limites qui serait de 5E5 fichiers à surveiller.


2/ multiplier les surveillances pour différentes applications ; là je 
dirais de l’ordre de 10E4-10E6 fichiers maximum. Je ne vois pas des 
milliards de fichiers à surveiller.
Là, inotify devrait encore pouvoir servir si on ne dépasse pas sa 
fameuse limite.



Mais dix millions de fichiers à surveiller, ça me parait beaucoup. Oui 
bien alors, faire une programmation fine (multi-thread, mulit-processus) 
qui prendra du temps (des mois de travail) et nécessiterait un 
ordinateur coûteux (serveur ou desktop à 10k€, pas un NAS à 500€).



Je ne crois pas à une solution simple, rapide (basée sur inotify) et 
100% fiable pour dix millions de fichiers, ou bien alors il faut 
développer un gros logiciel  Le diable est dans les détails.



Pour ma part, je cherche des partenaires intéressés par le projet 
logiciel libre /RefPerSys/ en http://refpersys.org/ - contactez moi 
alors par courriel (peut-être même au bureau CEA LIST 
 en basile.starynkevi...@cea.fr)



Bonne soirée.


--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: Détecter un changement dans un répertoire

2023-01-12 Par sujet RogerT 
Pourquoi : pour prendre des décisions de traitement sur évènement « fichier 
créé/modifié/supprimé/etc. ».

FS : ext4 ou btrfs ou nfs. 

Qté de fichiers : il y a différents cas ; 
1/ surveiller un répertoire où sont déposés des fichiers régulièrement, qui 
vont en être enlevés après traitement ; ici, le nombre de fichiers présents à 
chaque instant sera de l’ordre d’une centaine, voire d’un millier pour 
constituer une file d’attente si le traitement est long et que le flux de dépôt 
de fichiers augmente.  
Là, je crois que inotify et ses dérivés devraient faire l’affaire sans 
atteindre ses limites qui serait de 5E5 fichiers à surveiller.

2/ multiplier les surveillances pour différentes applications ; là je dirais de 
l’ordre de 10E4-10E6 fichiers maximum. Je ne vois pas des milliards de fichiers 
à surveiller. 
Là, inotify devrait encore pouvoir servir si on ne dépasse pas sa fameuse 
limite.

Volume de fichiers : je dirais Go-To, mais pas Po (fichiers texte, images, pdf, 
etc.)


> Le 12 janv. 2023 à 18:35, Basile Starynkevitch  a 
> écrit :
> 
> 
> 
> 
> On 12/01/2023 15:57, roger.tar...@free.fr wrote:
>> Bonjour,
>> et encore bonne année à tous,
>> 
>> Je cherche à surveiller ce qui se passe dans un répertoire.
> 
> Pourquoi et dans quel but? Quel est le problème que vous voulez résoudre? Sir 
> quel volume de données (méga-octets, péta-octets) et quel nombre de fichiers 
> (centaines, ou millins) et dans quel système de fichier (ext4, btrfs, NFS, 
> ...) ? Un grand nombre d'utilitaires surveillent des fichiers (je pense à 
> GNU make )
> 
> 
> 
> 
> 
> Pour ma part, je cherche des partenaires intéressés par RefPerSys en 
> http://refpersys.org/ - contactez moi alors par courriel.
> 
> Bonne année 2023.
> 
> 
> 
> Cordialement
> 
> -- 
> Basile Starynkevitch  
> (only mine opinions / les opinions sont miennes uniquement)
> 92340 Bourg-la-Reine, France
> web page: starynkevitch.net/Basile/
>

Re: Détecter un changement dans un répertoire

2023-01-12 Par sujet Basile Starynkevitch 


On 12/01/2023 15:57, roger.tar...@free.fr wrote:

Bonjour,
et encore bonne année à tous,

Je cherche à surveiller ce qui se passe dans un répertoire.



Pourquoi et dans quel but? Quel est le problème que vous voulez 
résoudre? Sir quel volume de données (méga-octets, péta-octets) et quel 
nombre de fichiers (centaines, ou millins) et dans quel système de 
fichier (ext4, btrfs, NFS, ...) ? Un grand nombre d'utilitaires 
surveillent des fichiers (je pense à GNU make )




Pour ma part, je cherche des partenaires intéressés par RefPerSys en 
http://refpersys.org/ - contactez moi alors par courriel.


Bonne année 2023.


Cordialement

--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: Détecter un changement dans un répertoire

2023-01-12 Par sujet RogerT 
Je ne connaissais pas. Merci. 

incron n’est pas récursif. 
Et ne gère pas d’historique. Ce tuto parle de créer un historique (à la 
seconde, dans laquelle on ne sait pas l’ordre d’arrivée des fichiers). 
https://www.geeksforgeeks.org/incron-command-in-linux-with-examples/

> Le 12 janv. 2023 à 16:01, NoSpam  a écrit :
> 
> Bonjour
> 
> Le 12/01/2023 à 15:57, roger.tar...@free.fr a écrit :
>> Bonjour,
>> et encore bonne année à tous,
>> 
>> Je cherche à surveiller ce qui se passe dans un répertoire.
>> 
>> Il semble exister plusieurs solutions.
>> La plus basique consiste à examiner les fichiers déposés, par exemple toutes 
>> les minutes (via cron ou avec un programme qui tourne en boucle et se met en 
>> pause 1 mn après chaque boucle).
>> Je suis plus intéressé par une programmation événementielle où le programme 
>> réagit si de nouveaux fichiers sont déposés ou modifiés et détectés par le 
>> système.
>> Pour faire ça, j'avais examiné inotify mais constaté qu'il y aurait des 
>> limitations (de mémoire, par exemple, sur le nombre de fichiers traitables, 
>> de inode, etc.).
>> 
>> J'ai repéré notamment : auditd, fswatch, inotify/inotifywait.
>> 
>> Selon vous, pour traiter ce besoin quelle est la solution _FIABLE_ ? (cad 
>> qui ne provoque pas d'effets de bord... ou de surprise)
>> 
>> Par ailleurs, pour traiter le cas où des fichiers dépendants les uns des 
>> autres sont déposés en vrac, il serait intéressant de pouvoir disposer d'un 
>> historique détaillé par fichier, exploitable.
>> Je suppose que ça doit être prévu (inotify le fait).
> incron fait cela à la perfection

Re: Détecter un changement dans un répertoire

2023-01-12 Par sujet Fab 

hello,


incron fait cela à la perfection

yes.
et c'est inotify qui est utilisé.

f.

Re: Détecter un changement dans un répertoire

2023-01-12 Par sujet NoSpam 

Bonjour

Le 12/01/2023 à 15:57, roger.tar...@free.fr a écrit :

Bonjour,
et encore bonne année à tous,

Je cherche à surveiller ce qui se passe dans un répertoire.

Il semble exister plusieurs solutions.
La plus basique consiste à examiner les fichiers déposés, par exemple 
toutes les minutes (via cron ou avec un programme qui tourne en boucle 
et se met en pause 1 mn après chaque boucle).
Je suis plus intéressé par une programmation événementielle où le 
programme réagit si de nouveaux fichiers sont déposés ou modifiés et 
détectés par le système.
Pour faire ça, j'avais examiné inotify mais constaté qu'il y aurait 
des limitations (de mémoire, par exemple, sur le nombre de fichiers 
traitables, de inode, etc.).


J'ai repéré notamment : auditd, fswatch, inotify/inotifywait.

Selon vous, pour traiter ce besoin quelle est la solution *_FIABLE_* ? 
(cad qui ne provoque pas d'effets de bord... ou de surprise)


Par ailleurs, pour traiter le cas où des fichiers dépendants les uns 
des autres sont déposés en vrac, il serait intéressant de pouvoir 
disposer d'un historique détaillé par fichier, exploitable.

Je suppose que ça doit être prévu (inotify le fait).

incron fait cela à la perfection