Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS Linux inotify sur un repertoire: le champs inotify_event.len semble rester=0 pour un repertoire

inotify sur un repertoire: le champs inotify_event.len semble rester=0 pour un repertoire

82 réponses
Avatar
Zeyes
J'ai poste ca aussi sur fr.comp.os.linux.debats parceque ca bouge pas
mal la-bas..
;-)

Bonour,
j"ai regarde
http://www.linuxjournal.com/node/8478/print
Extrait:
"
The name field contains the name of the object to which the event
occurred, relative to wd, if applicable. For example, if a watch for
writes in /etc triggers an event on the writing to /etc/vimrc, the name
field will contain vimrc, and the wd field will link back to the /etc watch
"
Mais ca marche pas chez moi: le champs inotify_event.len reste a 0,
alors qu'il semble rester des octets a lire...
quelqu'un a une idee?
Est-ce normal? Pas encore implemente?
Merci
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4 5
Avatar
Luc.Habert.00__arjf
Zeyes :

Et ca n'arrete plus de boucler (comme s'il y a vait encore des octetes)
plein de

coucou
lg nom: 0

Strange, non?


Ça sent le read qui ne renvoie rien. Lance ton a.out via

strace -o /tmp/blah ./a.out tata "echo coucou"

, et regarde dans le fichier /tmp/blah, tu as la trace des appels systèmes
effectués.

Avatar
Zeyes
Zeyes :

Et ca n'arrete plus de boucler (comme s'il y a vait encore des octetes)
plein de

coucou
lg nom: 0

Strange, non?


Ça sent le read qui ne renvoie rien. Lance ton a.out via

strace -o /tmp/blah ./a.out tata "echo coucou"

, et regarde dans le fichier /tmp/blah, tu as la trace des appels systèmes
effectués.
Bon, ben y'a du monde la-dedans...



Avatar
Zeyes
Zeyes :

Et ca n'arrete plus de boucler (comme s'il y a vait encore des octetes)
plein de

coucou
lg nom: 0

Strange, non?


Ça sent le read qui ne renvoie rien. Lance ton a.out via

strace -o /tmp/blah ./a.out tata "echo coucou"

, et regarde dans le fichier /tmp/blah, tu as la trace des appels systèmes
effectués.
Bon y'a:


execve("./a.out", ["./a.out", "tata", "echo coucou"], [/* 72 vars */]) = 0
brk(0) = 0x804a000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7fce000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size3880, ...}) = 0
mmap2(NULL, 113880, PROT_READ, MAP_PRIVATE, 4, 0) = 0xb7fb2000
close(4) = 0
open("/lib/i686/libc.so.6", O_RDONLY) = 4
read(4, "177ELF111331240X1"...,
512) = 512
fstat64(4, {st_mode=S_IFREG|0644, st_size20244, ...}) = 0
mmap2(NULL, 1230204, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4,
0) = 0xb7e85000
mmap2(0xb7fac000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x126) = 0xb7fac000
mmap2(0xb7faf000, 9596, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7faf000
close(4) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7e84000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e846c0,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7fac000, 4096, PROT_READ) = 0
mprotect(0xb7fe7000, 4096, PROT_READ) = 0
munmap(0xb7fb2000, 113880) = 0
fstat64(1, {st_mode=S_IFCHR|0600, st_size=makedev(0, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7fcd000
write(1, "surveille tatan", 15) = 15
SYS_291(0xb7fadff4, 0, 0xb7faf0b0, 0xb7fe7ce0, 0) = 4
SYS_292(0x4, 0xbf9fd5ef, 0x2, 0xb7fe7ce0, 0) = 1
poll([{fd=4, events=POLLIN, revents=POLLIN}], 1, -1) = 1
read(4, "", 16) = 0
write(1, "lg nom: 0n", 10) = 10
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD,
parent_tidptr=0xbf9fb114) = 13860
waitpid(13860, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 13860
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---

Puis ca boucle:

poll([{fd=4, events=POLLIN, revents=POLLIN}], 1, -1) = 1
read(4, "", 16) = 0
write(1, "lg nom: 0n", 10) = 10
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD,
parent_tidptr=0xbf9fb114) = 13861
waitpid(13861, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 13861
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---

Tiens.. ca utilise sigaction... ;-)


Avatar
Nicolas George
Luc Habert wrote in message <evu92a$2ern$:
(ça, c'est
valable avec tous les appels systèmes qui peuvent bloquer)


Sauf connect.

Avatar
Zeyes
Il est inutile de poller, tu pourrais faire un read directement, et laisser
le noyau te bloquer tant qu'il n'y a rien à lire.
J'ai cru comprendre que poll() ne polait pas, mais restait en attente

sur un evenemnet, d'apres le man... ca me semblait bien.

Avatar
Nicolas George
Zeyes wrote in message <4622b877$0$27414$:
J'ai cru comprendre que poll() ne polait pas, mais restait en attente
sur un evenemnet, d'apres le man... ca me semblait bien.


Il reste en attente sur plusieurs événements avec une limite de temps. Si tu
n'as qu'un seul événement et pas de limite de temps, ça ne sert à rien.

Franchement, tu as peut-être des connaissances, mais elles sont trop
approximatives et mal digérées. Paye-toi le K&R et APUE, commence doucement
au début, fais les exercices, ça ira mieux.

Avatar
Luc.Habert.00__arjf
Zeyes :

poll([{fd=4, events=POLLIN, revents=POLLIN}], 1, -1) = 1
read(4, "", 16) = 0


Bien, le read ne lit rien du tout... Et je n'y comprends rien du tout. Enfin
vu à quel point la sémantique du fd renvoyé par inotify_init est non
documentée, ce n'est pas étonnant. Il faudrait aller lire le code source du
noyau.

Avatar
Luc.Habert.00__arjf
Zeyes :

Il est inutile de poller, tu pourrais faire un read directement, et laisser
le noyau te bloquer tant qu'il n'y a rien à lire.
J'ai cru comprendre que poll() ne polait pas



Oui, j'employais « poller » au sens « appeller poll ».


Avatar
Zeyes
Zeyes wrote in message <4622b877$0$27414$:
J'ai cru comprendre que poll() ne polait pas, mais restait en attente
sur un evenemnet, d'apres le man... ca me semblait bien.


Il reste en attente sur plusieurs événements avec une limite de temps. Si tu
n'as qu'un seul événement et pas de limite de temps, ça ne sert à rien.
Ben si: a attendre le seul evenement qui m'interesse!

Developpe!

Franchement, tu as peut-être des connaissances, mais elles sont trop
approximatives et mal digérées. Paye-toi le K&R et APUE, commence doucement
au début, fais les exercices, ça ira mieux.
Connais pas, et je veux plus payer!

Mes conaissances sont surtout W$iennes... desole.. mais je ne cherche
qu'a apprendre. Pourquoi tant d'agressivite?
Explique! Je suis tout oui !


Avatar
Zeyes
Zeyes :

poll([{fd=4, events=POLLIN, revents=POLLIN}], 1, -1) = 1
read(4, "", 16) = 0


Bien, le read ne lit rien du tout... Et je n'y comprends rien du tout. Enfin
vu à quel point la sémantique du fd renvoyé par inotify_init est non
documentée, ce n'est pas étonnant. Il faudrait aller lire le code source du
noyau.
Bon, j'ai ca... je m'y plongerai... demain! La il est un peu tard.



1 2 3 4 5