• =?utf-8?Q?D=C3=A9tecter_un_changement_dans_un_r=C3=A9pertoire?=

    From [email protected]@21:1/5 to All on Thu Jan 12 16:00:02 2023
    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

    <html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>Bonjour,</div><div>et encore bonne année à tous,<br><br>Je cherche à surveiller ce qui se passe dans un répertoire. </div><div><br>Il semble
    exister plusieurs solutions.<br>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).<br>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.<br>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.).<br><br>J'ai repéré notamment : auditd, fswatch, inotify/inotifywait.<br><br>Selon vous, pour traiter ce besoin quelle est la solution <strong>_FIABLE_</strong> ? (cad qui ne provoque pas d'
    effets de bord... ou de surprise)<br><br>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.<br>Je
    suppose que ça doit être prévu (inotify le fait).<br><br>Merci <br></div></div></body></html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From NoSpam@21:1/5 to All on Thu Jan 12 16:10:01 2023
    This is a multi-part message in MIME format.
    Bonjour

    Le 12/01/2023 à 15:57, [email protected] 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
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <p>Bonjour<br>
    </p>
    <div class="moz-cite-prefix">Le 12/01/2023 à 15:57,
    <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> a écrit :<br>
    </div>
    <blockquote type="cite"
    cite="mid:[email protected]">
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <div style="font-family: arial, helvetica, sans-serif; font-size:
    12pt; color: #000000">
    <div>Bonjour,</div>
    <div>et encore bonne année à tous,<br>
    <br>
    Je cherche à surveiller ce qui se passe dans un répertoire. </div>
    <div><br>
    Il semble exister plusieurs solutions.<br>
    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).<br>
    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.<br>
    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.).<br>
    <br>
    J'ai repéré notamment : auditd, fswatch, inotify/inotifywait.<br>
    <br>
    Selon vous, pour traiter ce besoin quelle est la solution <strong>_FIABLE_</strong>
    ? (cad qui ne provoque pas d'effets de bord... ou de surprise)<br>
    <br>
    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.<br>
    Je suppose que ça doit être prévu (inotify le fait).<br>
    </div>
    </div>
    </blockquote>
    incron fait cela à la perfection<br>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fab@21:1/5 to All on Thu Jan 12 17:00:01 2023
    hello,

    incron fait cela à la perfection
    yes.
    et c'est inotify qui est utilisé.

    f.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From RogerT@21:1/5 to All on Thu Jan 12 17:20:01 2023
    --Apple-Mail-6C44E423-BA73-443D-B29D-55E141E3B468
    Content-Type: text/plain;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    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 <[email protected]> a écrit :
    
    Bonjour

    Le 12/01/2023 à 15:57, [email protected] 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

    --Apple-Mail-6C44E423-BA73-443D-B29D-55E141E3B468
    Content-Type: text/html;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    <html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="ltr"></div><div dir="ltr">Je ne connaissais pas. Merci.&
    nbsp;</div><div dir="ltr"><br></div><div dir="ltr">incron n’est pas récursif.&nbsp;</div><div dir="ltr">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).&nbsp;</div><div dir="ltr"><a href="https://www.geeksforgeeks.org/incron-command-in-linux-with-examples/">https://www.geeksforgeeks.org/incron-command-in-linux-with-examples/</a></div><div dir="ltr"><br><blockquote type="cite">Le 12 janv. 2023 �
    � 16:01, NoSpam &lt;[email protected]&gt; a écrit&nbsp;:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">


    <p>Bonjour<br>
    </p>
    <div class="moz-cite-prefix">Le 12/01/2023 à 15:57,
    <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> a écrit&nbsp;:<br>
    </div>
    <blockquote type="cite" cite="mid:[email protected]">
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <div style="font-family: arial, helvetica, sans-serif; font-size:
    12pt; color: #000000">
    <div>Bonjour,</div>
    <div>et encore bonne année à tous,<br>
    <br>
    Je cherche à surveiller ce qui se passe dans un répertoire. </div>
    <div><br>
    Il semble exister plusieurs solutions.<br>
    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).<br>
    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.<br>
    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.).<br>
    <br>
    J'ai repéré notamment : auditd, fswatch, inotify/inotifywait.<br>
    <br>
    Selon vous, pour traiter ce besoin quelle est la solution <strong>_FIABLE_</strong>
    ? (cad qui ne provoque pas d'effets de bord... ou de surprise)<br>
    <br>
    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.<br>
    Je suppose que ça doit être prévu (inotify le fait).<br>
    </div>
    </div>
    </blockquote>
    incron fait cela à la perfection<br>


    </div></blockquote></div></body></html> --Apple-Mail-6C44E423-BA73-443D-B29D-55E141E3B468--

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Basile Starynkevitch@21:1/5 to [email protected] on Thu Jan 12 18:40:01 2023
    This is a multi-part message in MIME format.
    On 12/01/2023 15:57, [email protected] 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<[email protected]>
    (only mine opinions / les opinions sont miennes uniquement)
    92340 Bourg-la-Reine, France
    web page: starynkevitch.net/Basile/

    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 12/01/2023 15:57,
    <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> wrote:<br>
    </div>
    <blockquote type="cite"
    cite="mid:[email protected]">
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <div style="font-family: arial, helvetica, sans-serif; font-size:
    12pt; color: #000000">
    <div>Bonjour,</div>
    <div>et encore bonne année à tous,<br>
    <br>
    Je cherche à surveiller ce qui se passe dans un répertoire. </div>
    </div>
    </blockquote>
    <p><br>
    </p>
    <p>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 ....)</p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p>Pour ma part, je cherche des partenaires intéressés par RefPerSys
    en <a class="moz-txt-link-freetext" href="http://refpersys.org/">http://refpersys.org/</a> - contactez moi alors par courriel.</p>
    <p>Bonne année 2023.</p>
    <p><br>
    </p>
    <p>Cordialement<br>
    </p>
    <pre class="moz-signature" cols="72">--
    Basile Starynkevitch <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]">&lt;[email protected]&gt;</a>
    (only mine opinions / les opinions sont miennes uniquement)
    92340 Bourg-la-Reine, France
    web page: starynkevitch.net/Basile/

    </pre>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From RogerT@21:1/5 to All on Thu Jan 12 18:20:01 2023
    --Apple-Mail-BEB31586-0255-4079-9939-ECFF018D7E09
    Content-Type: text/plain;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    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

    inotifywatch --recursive

    « 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. »

    5.2. inotify Watch Limit

    Consider that a recursive inotifywatch on / would take up as many watches as there are files. Indeed, doing that on a filesystem with more files than the watch limit would produce an error:



    etc.

    Avez-vous une expérience avec la récursivité et les limites que cela peut engendrer avec les limites ?

    Début du message transféré :

    De: NoSpam <[email protected]>
    Date: 12 janvier 2023 à 16:01:21 UTC+1
    À: [email protected]
    Objet: Rép. : Détecter un changement dans un répertoire
    Répondre à: [email protected]d

    
    Bonjour

    Le 12/01/2023 à 15:57, [email protected] 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

    --Apple-Mail-BEB31586-0255-4079-9939-ECFF018D7E09
    Content-Type: text/html;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    <html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="ltr"></div><div dir="ltr">Cet article&nbsp;de janvier 2022
    apporte des réponses sur la limite et la récursivité :</div><div dir="ltr"><div dir="ltr"><a href="https://www.baeldung.com/linux/inotify-upper-limit-reached">https://www.baeldung.com/linux/inotify-upper-limit-reached</a></div><div dir="ltr"><br></div>
    <div dir="ltr"><span style="font-family: &quot;Source Code Pro&quot;, Consolas, &quot;Bitstream Vera Sans Mono&quot;, &quot;Courier New&quot;, Courier, monospace; font-size: 14px; white-space: pre-wrap; -webkit-tap-highlight-color: rgba(0, 0, 0, 0); -
    webkit-text-size-adjust: 100%; background-color: rgb(250, 250, 250);">inotifywatch --recursive</span></div><div dir="ltr"><span style="font-family: &quot;Source Code Pro&quot;, Consolas, &quot;Bitstream Vera Sans Mono&quot;, &quot;Courier New&quot;,
    Courier, monospace; font-size: 14px; white-space: pre-wrap; -webkit-tap-highlight-color: rgba(0, 0, 0, 0); -webkit-text-size-adjust: 100%; background-color: rgb(250, 250, 250);"><br></span></div><div dir="ltr"></div><div dir="ltr">«&nbsp;<span style="
    font-family: Raleway, sans-serif; font-size: 18px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0); -webkit-text-size-adjust: 100%; background-color: rgb(255, 255, 255);">Here, the system allows&nbsp;</span><em style="box-sizing: border-box; font-family:
    Raleway, sans-serif; font-size: 18px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0); -webkit-text-size-adjust: 100%;">524288</em><span style="font-family: Raleway, sans-serif; font-size: 18px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0); -webkit-text-
    size-adjust: 100%; background-color: rgb(255, 255, 255);">&nbsp;(2^19) watches. »</span></div><div dir="ltr"><span style="font-family: Raleway, sans-serif; font-size: 18px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0); -webkit-text-size-adjust: 100%;
    background-color: rgb(255, 255, 255);"><br></span></div><div dir="ltr"><span style="font-family: Raleway, sans-serif; font-size: 18px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0); -webkit-text-size-adjust: 100%; background-color: rgb(255, 255, 255);">«
    &nbsp;</span><span style="font-family: Raleway, sans-serif; font-size: 18px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0); -webkit-text-size-adjust: 100%; background-color: rgb(255, 255, 255);">Because each watch is a structure,&nbsp;</span><strong
    style="box-sizing: border-box; font-family: Raleway, sans-serif; font-size: 18px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0); -webkit-text-size-adjust: 100%;">available memory is also a bottleneck for using&nbsp;<em style="box-sizing: border-box;">
    inotify</em></strong><span style="font-family: Raleway, sans-serif; font-size: 18px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0); -webkit-text-size-adjust: 100%; background-color: rgb(255, 255, 255);">. In fact, a watch can take up to 1KB of space.
    This means a million watches could result in 1GB of extra RAM usage. »</span></div><div dir="ltr"><span style="font-family: Raleway, sans-serif; font-size: 18px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0); -webkit-text-size-adjust: 100%; background-
    color: rgb(255, 255, 255);"><br></span></div><div dir="ltr"><h3 id="bd-2-inotify-watch-limit" data-id="2-inotify-watch-limit" style="font-family: inherit; -webkit-text-size-adjust: auto; box-sizing: border-box; position: relative; line-height: 1.1;
    margin-top: 2.1em; margin-bottom: 1.3em; font-size: 24px;">5.2.&nbsp;<em style="box-sizing: border-box;">inotify</em>&nbsp;Watch Limit</h3><pre class="hljs-copy-wrapper" style="font-size: 1em; -webkit-text-size-adjust: auto; box-sizing: border-box; font-
    family: monospace, monospace; position: relative; overflow: hidden; word-wrap: break-word; --hljs-theme-background: rgb(250, 250, 250);"><p style="white-space: normal; box-sizing: border-box; margin: 0px 0px 10px; line-height: 1.334;">Consider that&nbsp;<
    strong style="box-sizing: border-box;">a recursive&nbsp;<em style="box-sizing: border-box;">inotifywatch&nbsp;</em>on&nbsp;<em style="box-sizing: border-box;">/</em>&nbsp;would take up as many watches as there are files</strong>. Indeed, doing that on a
    filesystem with more files than the watch limit would produce an error:</p><p style="white-space: normal; box-sizing: border-box; margin: 0px 0px 10px; line-height: 1.334;"><br></p><p style="white-space: normal; box-sizing: border-box; margin: 0px 0px
    10px; line-height: 1.334;">etc.</p></pre></div><div dir="ltr">Avez-vous une expérience avec la récursivité et les limites que cela peut engendrer avec les limites ?</div><br>Début du message transféré&nbsp;:<br><br></div><blockquote type="cite"><
    div dir="ltr"><b>De:</b> NoSpam &lt;[email protected]&gt;<br><b>Date:</b> 12 janvier 2023 à 16:01:21 UTC+1<br><b>À:</b> [email protected]<br><b>Objet:</b> <b>Rép.&nbsp;: Détecter un changement dans un répertoire</b><br><b>Ré
    pondre à:</b> [email protected]d<br><br></div></blockquote><blockquote type="cite"><div dir="ltr">

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">


    <p>Bonjour<br>
    </p>
    <div class="moz-cite-prefix">Le 12/01/2023 à 15:57,
    <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> a écrit&nbsp;:<br>
    </div>
    <blockquote type="cite" cite="mid:[email protected]">
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <div style="font-family: arial, helvetica, sans-serif; font-size:
    12pt; color: #000000">
    <div>Bonjour,</div>
    <div>et encore bonne année à tous,<br>
    <br>
    Je cherche à surveiller ce qui se passe dans un répertoire. </div>
    <div><br>
    Il semble exister plusieurs solutions.<br>
    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).<br>
    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.<br>
    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.).<br>
    <br>
    J'ai repéré notamment : auditd, fswatch, inotify/inotifywait.<br>
    <br>
    Selon vous, pour traiter ce besoin quelle est la solution <strong>_FIABLE_</strong>
    ? (cad qui ne provoque pas d'effets de bord... ou de surprise)<br>
    <br>
    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.<br>
    Je suppose que ça doit être prévu (inotify le fait).<br>
    </div>
    </div>
    </blockquote>
    incron fait cela à la perfection<br>


    </div></blockquote></div></body></html> --Apple-Mail-BEB31586-0255-4079-9939-ECFF018D7E09--

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From RogerT@21:1/5 to All on Thu Jan 12 20:20:01 2023
    --Apple-Mail-6F08694F-8660-4A0C-AE9B-24D4EA49D9FD
    Content-Type: text/plain;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    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 <[email protected]> a écrit :

    


    On 12/01/2023 15:57, [email protected] 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 <[email protected]>
    (only mine opinions / les opinions sont miennes uniquement)
    92340 Bourg-la-Reine, France
    web page: starynkevitch.net/Basile/


    --Apple-Mail-6F08694F-8660-4A0C-AE9B-24D4EA49D9FD
    Content-Type: text/html;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    <html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Pourquoi : pour prendre des décisions de traitement sur évènement « fichier créé/modifié/supprimé/etc. ».</
    <div dir="ltr"><br></div><div dir="ltr">FS : ext4 ou btrfs ou nfs.&nbsp;</div><div dir="ltr"><br></div><div dir="ltr">Qté de fichiers : il y a différents cas ;&nbsp;</div><div dir="ltr">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. &nbsp;</div><div dir="ltr">Là, je crois que inotify et ses dérivés devraient faire l’affaire sans atteindre ses limites qui serait de 5E5 fichiers à surveiller.</div><div dir="ltr"><br></div><div dir="ltr">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.&nbsp;</div><div dir="ltr">Là, inotify devrait encore pouvoir servir si on ne
    dépasse pas sa fameuse limite.</div><div dir="ltr"><br></div><div dir="ltr">Volume de fichiers : je dirais Go-To, mais pas Po (fichiers texte, images, pdf, etc.)</div><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">Le 12 janv. 2023 à
    18:35, Basile Starynkevitch &lt;[email protected]&gt; a écrit&nbsp;:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">


    <p><br>
    </p>
    <div class="moz-cite-prefix">On 12/01/2023 15:57,
    <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:[email protected]">
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <div style="font-family: arial, helvetica, sans-serif; font-size:
    12pt; color: #000000">
    <div>Bonjour,</div>
    <div>et encore bonne année à tous,<br>
    <br>
    Je cherche à surveiller ce qui se passe dans un répertoire. </div>
    </div>
    </blockquote>
    <p><br>
    </p>
    <p>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 ....)</p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p>Pour ma part, je cherche des partenaires intéressés par RefPerSys
    en <a class="moz-txt-link-freetext" href="http://refpersys.org/">http://refpersys.org/</a> - contactez moi alors par courriel.</p>
    <p>Bonne année 2023.</p>
    <p><br>
    </p>
    <p>Cordialement<br>
    </p>
    <pre class="moz-signature" cols="72">--
    Basile Starynkevitch <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]">&lt;[email protected]&gt;</a>
    (only mine opinions / les opinions sont miennes uniquement)
    92340 Bourg-la-Reine, France
    web page: starynkevitch.net/Basile/

    </pre>


    </div></blockquote></body></html> --Apple-Mail-6F08694F-8660-4A0C-AE9B-24D4EA49D9FD--

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Basile Starynkevitch@21:1/5 to RogerT on Thu Jan 12 21:00:01 2023
    This is a multi-part message in MIME format.
    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) <https://man7.org/linux/man-pages/man2/mmap.2.html>,msync(2) <https://man7.org/linux/man-pages/man2/msync.2.html>, andmunmap(2) <https://man7.org/linux/man-pages/man2/munmap.2.html>.

    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
    <https://list.cea.fr/> en [email protected])


    Bonne soirée.


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

    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 12/01/2023 20:16, RogerT wrote:<br>
    </div>
    <blockquote type="cite"
    cite="mid:[email protected]">
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <div dir="ltr">Pourquoi : pour prendre des décisions de traitement
    sur évènement « fichier créé/modifié/supprimé/etc. ».</div>
    <div dir="ltr"><br>
    </div>
    <div dir="ltr">FS : ext4 ou btrfs ou nfs. <br>
    </div>
    </blockquote>
    <p><br>
    </p>
    <p>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).</p>
    <p><br>
    </p>
    <blockquote type="cite"
    cite="mid:[email protected]">
    <div dir="ltr"><br>
    </div>
    <div dir="ltr">Qté de fichiers : il y a différents cas ; </div>
    <div dir="ltr">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.  <br>
    </div>
    </blockquote>
    <p><br>
    </p>
    <p>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 <a
    moz-do-not-send="true"
    href="https://man7.org/linux/man-pages/man7/inotify.7.html"
    class="moz-txt-link-freetext">https://man7.org/linux/man-pages/man7/inotify.7.html</a>
    où on peut lire les limitations:<br>
    </p>
    <p>
    <blockquote type="cite">
    <pre> The inotify API does not report file accesses and modifications
    that may occur because of <a href="https://man7.org/linux/man-pages/man2/mmap.2.html">mmap(2)</a>, <a href="https://man7.org/linux/man-pages/man2/msync.2.html">msync(2)</a>, and <a href="https://man7.org/linux/man-pages/man2/munmap.2.html">munmap(
    2)</a>.
    </pre>
    </blockquote>
    <br>
    </p>
    <blockquote type="cite"
    cite="mid:[email protected]">
    <div dir="ltr">Là, je crois que inotify et ses dérivés devraient
    faire l’affaire sans atteindre ses limites qui serait de 5E5
    fichiers à surveiller.</div>
    <div dir="ltr"><br>
    </div>
    <div dir="ltr">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. </div>
    <div dir="ltr">Là, inotify devrait encore pouvoir servir si on ne
    dépasse pas sa fameuse limite.</div>
    </blockquote>
    <p><br>
    </p>
    <p>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€).</p>
    <p><br>
    </p>
    <p>Je ne crois pas à une solution simple, rapide (basée sur <font
    face="monospace">inotify</font>) 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.<br>
    </p>
    <p><br>
    </p>
    <p>Pour ma part, je cherche des partenaires intéressés par le projet
    logiciel libre <i>RefPerSys</i> en <a moz-do-not-send="true"
    href="http://refpersys.org/" class="moz-txt-link-freetext">http://refpersys.org/</a>
    - contactez moi alors par courriel (peut-être même au bureau <a
    moz-do-not-send="true" href="https://list.cea.fr/">CEA LIST</a>
    en <font face="monospace"><a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a></font>)<br>
    </p>
    <p><br>
    </p>
    <p>Bonne soirée.</p>
    <p><br>
    </p>
    <pre class="moz-signature" cols="72">--
    Basile Starynkevitch <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]">&lt;[email protected]&gt;</a>
    (only mine opinions / les opinions sont miennes uniquement)
    92340 Bourg-la-Reine, France
    web page: starynkevitch.net/Basile/

    </pre>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to All on Thu Jan 12 23:00:01 2023
    De: "Basile Starynkevitch" <[email protected]>
    À: "Liste Debian" <[email protected]>
    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:[email protected] | [email protected] ] )


    Bonne soirée.


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


    <html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div data-marker="__QUOTED_TEXT__"><div style="font-family:'arial' , 'helvetica' , sans-serif;font-size:12pt;color:#000000"><br><br><hr id="zwchr"><div><b>
    De: </b>"Basile Starynkevitch" &lt;[email protected]&gt;<br><b>À: </b>"Liste Debian" &lt;[email protected]&gt;<br><b>Envoyé: </b>Jeudi 12 Janvier 2023 20:59:25<br><b>Objet: </b>Re: Détecter un changement dans un répertoire<br>
    </div><br><div><p><br>
    </p>
    <div class="moz-cite-prefix">On 12/01/2023 20:16, RogerT wrote:<br>
    </div>
    <blockquote>

    <div dir="ltr">Pourquoi : pour prendre des décisions de traitement
    sur évènement « fichier créé/modifié/supprimé/etc.
  • From benoit@21:1/5 to All on Sat Jan 14 15:40:01 2023
    This is a multi-part message in MIME format.

    Sid1dGlsaXNlIGxzeW5jZCBwb3VyIHN5bmNocm9uaXNlciBkZXMgZGlzcXVlcyBvdSByw6lwZXJ0 b2lyZS4KaHR0cHM6Ly9naXRodWIuY29tL2xzeW5jZC9sc3luY2QKCkNlIG4nZXN0IHBhcyBjZSBx dWUgdHUgcmVjaGVyY2hlcywgbWFpcyBsZSBtw6ljYW5pc21lIGRlIHN1cnZlaWxsYW5jZSBxdSd1 dGlsaXNlIGxzeW5jZCwgY29ycmVzcG9uZCDDoCB0YSByZWNoZXJjaGUKSWwgbWUgc2VtYmxlLCAo w6AgdsOpcmlmaWVyKSBxdWUgYydlc3QgaW5vdGlmeSBxdWkgZXN0IHV0aWxpc8OpIHBvdXIgc3Vy dmVpbGxlciBsZXMgcsOpcGVydG9pcmVzIGV0IGTDqWNsZW5jaGVyIGxhIHN5bmNocm9uaXNhdGlv biBsb3JzIGQndW4gY2hhbmdlbWVudC4KCi0tCkJlbm9pdAoKLS0tLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tLS0KTGUgamV1ZGkgMTIgamFudmllciAyMDIzIMOgIDE1OjU3LCByb2dlci50YXJh bmlAZnJlZS5mciA8cm9nZXIudGFyYW5pQGZyZWUuZnI+IGEgw6ljcml0IDoKCj4gQm9uam91ciwK PiBldCBlbmNvcmUgYm9ubmUgYW5uw6llIMOgIHRvdXMsCj4KPiBKZSBjaGVyY2hlIMOgIHN1cnZl aWxsZXIgY2UgcXVpIHNlIHBhc3NlIGRhbnMgdW4gcsOpcGVydG9pcmUuCj4KPiBJbCBzZW1ibGUg ZXhpc3RlciBwbHVzaWV1cnMgc29sdXRpb25zLgo+IExhIHBsdXMgYmFzaXF1ZSBjb25zaXN0ZSDD oCBleGFtaW5lciBsZXMgZmljaGllcnMgZMOpcG9zw6lzLCBwYXIgZXhlbXBsZSB0b3V0ZXMgbGVz IG1pbnV0ZXMgKHZpYSBjcm9uIG91IGF2ZWMgdW4gcHJvZ3JhbW1lIHF1aSB0b3VybmUgZW4gYm91 Y2xlIGV0IHNlIG1ldCBlbiBwYXVzZSAxIG1uIGFwcsOocyBjaGFxdWUgYm91Y2xlKS4KPiBKZSBz dWlzIHBsdXMgaW50w6lyZXNzw6kgcGFyIHVuZSBwcm9ncmFtbWF0aW9uIMOpdsOpbmVtZW50aWVs bGUgb8O5IGxlIHByb2dyYW1tZSByw6lhZ2l0IHNpIGRlIG5vdXZlYXV4IGZpY2hpZXJzIHNvbnQg ZMOpcG9zw6lzIG91IG1vZGlmacOpcyBldCBkw6l0ZWN0w6lzIHBhciBsZSBzeXN0w6htZS4KPiBQ b3VyIGZhaXJlIMOnYSwgaidhdmFpcyBleGFtaW7DqSBpbm90aWZ5IG1haXMgY29uc3RhdMOpIHF1 J2lsIHkgYXVyYWl0IGRlcyBsaW1pdGF0aW9ucyAoZGUgbcOpbW9pcmUsIHBhciBleGVtcGxlLCBz dXIgbGUgbm9tYnJlIGRlIGZpY2hpZXJzIHRyYWl0YWJsZXMsIGRlIGlub2RlLCBldGMuKS4KPgo+ IEonYWkgcmVww6lyw6kgbm90YW1tZW50IDogYXVkaXRkLCBmc3dhdGNoLCBpbm90aWZ5L2lub3Rp Znl3YWl0Lgo+Cj4gU2Vsb24gdm91cywgcG91ciB0cmFpdGVyIGNlIGJlc29pbiBxdWVsbGUgZXN0 IGxhIHNvbHV0aW9uIF9GSUFCTEVfID8gKGNhZCBxdWkgbmUgcHJvdm9xdWUgcGFzIGQnZWZmZXRz IGRlIGJvcmQuLi4gb3UgZGUgc3VycHJpc2UpCj4KPiBQYXIgYWlsbGV1cnMsIHBvdXIgdHJhaXRl ciBsZSBjYXMgb8O5IGRlcyBmaWNoaWVycyBkw6lwZW5kYW50cyBsZXMgdW5zIGRlcyBhdXRyZXMg c29udCBkw6lwb3PDqXMgZW4gdnJhYywgaWwgc2VyYWl0IGludMOpcmVzc2FudCBkZSBwb3V2b2ly IGRpc3Bvc2VyIGQndW4gaGlzdG9yaXF1ZSBkw6l0YWlsbMOpIHBhciBmaWNoaWVyLCBleHBsb2l0 YWJsZS4KPiBKZSBzdXBwb3NlIHF1ZSDDp2EgZG9pdCDDqnRyZSBwcsOpdnUgKGlub3RpZnkgbGUg ZmFpdCkuCj4KPiBNZXJjaQ==

    PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7Ij5KJ3V0aWxp c2UgPHNwYW4+bHN5bmNkPC9zcGFuPiBwb3VyIHN5bmNocm9uaXNlciBkZXMgZGlzcXVlcyBvdSBy w6lwZXJ0b2lyZS48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyBmb250 LXNpemU6IDE0cHg7Ij48c3Bhbj48YSB0YXJnZXQ9Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIG5v Zm9sbG93IG5vb3BlbmVyIiBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbHN5bmNkL2xzeW5jZCI+ aHR0cHM6Ly9naXRodWIuY29tL2xzeW5jZC9sc3luY2Q8L2E+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsiPkNlIG4nZXN0 IHBhcyBjZSBxdWUgdHUgcmVjaGVyY2hlcywgbWFpcyBsZSBtw6ljYW5pc21lIGRlIHN1cnZlaWxs YW5jZSBxdSd1dGlsaXNlIDxzcGFuPmxzeW5jZDwvc3Bhbj4sIGNvcnJlc3BvbmQgw6AgdGEgcmVj aGVyY2hlPGJyPjwvZGl2PjxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrLXBy b3RvbiI+SWwgbWUgc2VtYmxlLCAow6AgdsOpcmlmaWVyKSBxdWUgYydlc3QgPHNwYW4+aW5vdGlm eTwvc3Bhbj4gcXVpIGVzdCB1dGlsaXPDqSBwb3VyIHN1cnZlaWxsZXIgbGVzIHLDqXBlcnRvaXJl cyBldCBkw6ljbGVuY2hlciBsYSBzeW5jaHJvbmlzYXRpb24gbG9ycyBkJ3VuIGNoYW5nZW1lbnQu PC9kaXY+PGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2stcHJvdG9uIiBzdHls ZT0iZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMCwgMCwg MCk7Ij48YnI+PC9kaXY+PGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2stcHJv dG9uIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiBy Z2IoMCwgMCwgMCk7Ij4tLTwvZGl2PjxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJlX2Js b2NrLXByb3RvbiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBj b2xvcjogcmdiKDAsIDAsIDApOyI+QmVub2l0PGJyPjwvZGl2PjxkaXYgY2xhc3M9InByb3Rvbm1h aWxfc2lnbmF0dXJlX2Jsb2NrLXByb3RvbiI+PGJyPjwvZGl2Pjxicj48ZGl2IGNsYXNzPSJwcm90 b25tYWlsX3F1b3RlIj4NCiAgICAgICAgLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS08 YnI+DQogICAgICAgIExlIGpldWRpIDEyIGphbnZpZXIgMjAyMyDDoCAxNTo1Nywgcm9nZXIudGFy YW5pQGZyZWUuZnIgJmx0O3JvZ2VyLnRhcmFuaUBmcmVlLmZyJmd0OyBhIMOpY3JpdCZuYnNwOzo8 YnI+PGJyPg0KICAgICAgICA8YmxvY2txdW90ZSBjbGFzcz0icHJvdG9ubWFpbF9xdW90ZSIgdHlw ZT0iY2l0ZSI+DQogICAgICAgICAgICA8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogYXJpYWwsIGhl bHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMCI+PGRp dj5Cb25qb3VyLDwvZGl2PjxkaXY+ZXQgZW5jb3JlIGJvbm5lIGFubsOpZSDDoCB0b3VzLDxicj48 YnI+SmUgY2hlcmNoZSDDoCBzdXJ2ZWlsbGVyIGNlIHF1aSBzZSBwYXNzZSBkYW5zIHVuIHLDqXBl cnRvaXJlLiA8L2Rpdj48ZGl2Pjxicj5JbCBzZW1ibGUgZXhpc3RlciBwbHVzaWV1cnMgc29sdXRp b25zLjxicj5MYSBwbHVzIGJhc2lxdWUgY29uc2lzdGUgw6AgZXhhbWluZXIgbGVzIGZpY2hpZXJz IGTDqXBvc8OpcywgcGFyIGV4ZW1wbGUgdG91dGVzIGxlcyBtaW51dGVzICh2aWEgY3JvbiBvdSBh dmVjIHVuIHByb2dyYW1tZSBxdWkgdG91cm5lIGVuIGJvdWNsZSBldCBzZSBtZXQgZW4gcGF1c2Ug MSBtbiBhcHLDqHMgY2hhcXVlIGJvdWNsZSkuPGJyPkplIHN1aXMgcGx1cyBpbnTDqXJlc3PDqSBw YXIgdW5lIHByb2dyYW1tYXRpb24gw6l2w6luZW1lbnRpZWxsZSBvw7kgbGUgcHJvZ3JhbW1lIHLD qWFnaXQgc2kgZGUgbm91dmVhdXggZmljaGllcnMgc29udCBkw6lwb3PDqXMgb3UgbW9kaWZpw6lz IGV0IGTDqXRlY3TDqXMgcGFyIGxlIHN5c3TDqG1lLjxicj5Qb3VyIGZhaXJlIMOnYSwgaidhdmFp cyBleGFtaW7DqSBpbm90aWZ5IG1haXMgY29uc3RhdMOpIHF1J2lsIHkgYXVyYWl0IGRlcyBsaW1p dGF0aW9ucyAoZGUgbcOpbW9pcmUsIHBhciBleGVtcGxlLCBzdXIgbGUgbm9tYnJlIGRlIGZpY2hp ZXJzIHRyYWl0YWJsZXMsIGRlIGlub2RlLCBldGMuKS48YnI+PGJyPkonYWkgcmVww6lyw6kgbm90 YW1tZW50IDogYXVkaXRkLCBmc3dhdGNoLCBpbm90aWZ5L2lub3RpZnl3YWl0Ljxicj48YnI+U2Vs b24gdm91cywgcG91ciB0cmFpdGVyIGNlIGJlc29pbiBxdWVsbGUgZXN0IGxhIHNvbHV0aW9uIDxz dHJvbmc+X0ZJQUJMRV88L3N0cm9uZz4gPyAoY2FkIHF1aSBuZSBwcm92b3F1ZSBwYXMgZCdlZmZl dHMgZGUgYm9yZC4uLiBvdSBkZSBzdXJwcmlzZSk8YnI+PGJyPlBhciBhaWxsZXVycywgcG91ciB0 cmFpdGVyIGxlIGNhcyBvw7kgZGVzIGZpY2hpZXJzIGTDqXBlbmRhbnRzIGxlcyB1bnMgZGVzIGF1 dHJlcyBzb250IGTDqXBvc8OpcyBlbiB2cmFjLCBpbCBzZXJhaXQgaW50w6lyZXNzYW50IGRlIHBv dXZvaXIgZGlzcG9zZXIgZCd1biBoaXN0b3JpcXVlIGTDqXRhaWxsw6kgcGFyIGZpY2hpZXIsIGV4 cGxvaXRhYmxlLjxicj5KZSBzdXBwb3NlIHF1ZSDDp2EgZG9pdCDDqnRyZSBwcsOpdnUgKGlub3Rp ZnkgbGUgZmFpdCkuPGJyPjxicj5NZXJjaSA8YnI+PC9kaXY+PC9kaXY+DQogICAgICAgIDwvYmxv Y2txdW90ZT48YnI+DQogICAgPC9kaXY+

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)