Dans un programme en C, Je souhaite implanter un système de cache pour
une fonction qui doit retourner certaines informations contenues dans un
fichier :
La fonction garde en mémoire stat.st_dev, stat.st_ino et stat.st_mtime,
et toutes les informations du fichier.
Lorsqu'elle est appelée, elle construit le chemin du fichier à lire, et
fait un stat() sur ce chemin.
Si le triplet (stat.st_dev, stat.st_ino et stat.st_mtime) diffère de
celui gardé en mémoire, alors elle fait l'opération de lecture et garde
en mémoire (statique) les informations.
Ensuite, elle applique les critères (passé en argument) pour trouver
en mémoire les information demandée, et elle le retourne.
Le critère sur le triplet (stat.st_dev, stat.st_ino et stat.st_mtime)
vous semble-t'il robuste pour ce genre d'opération ? Si ces trois valeurs
n'ont pas changé, je n'ai pas besoin d'aller relire le fichier ?
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
Nicolas George
PIGUET Bruno wrote in message <heiv3q$pep$:
Le critère sur le triplet (stat.st_dev, stat.st_ino et stat.st_mtime) vous semble-t'il robuste pour ce genre d'opération ?
Ça dépend par rapport à quel genre de modifications. Par rapport à une utilisation normale, probablement, pour peu que l'horloge système soit à l'heure. S'il y a des considérations de sécurité, c'est plus risqué, en particulier parce qu'un utilisateur peut fixer le mtime à sa guise.
PIGUET Bruno wrote in message <heiv3q$pep$1@sxcom1.cnrm.meteo.fr>:
Le critère sur le triplet (stat.st_dev, stat.st_ino et stat.st_mtime)
vous semble-t'il robuste pour ce genre d'opération ?
Ça dépend par rapport à quel genre de modifications. Par rapport à une
utilisation normale, probablement, pour peu que l'horloge système soit à
l'heure. S'il y a des considérations de sécurité, c'est plus risqué, en
particulier parce qu'un utilisateur peut fixer le mtime à sa guise.
Le critère sur le triplet (stat.st_dev, stat.st_ino et stat.st_mtime) vous semble-t'il robuste pour ce genre d'opération ?
Ça dépend par rapport à quel genre de modifications. Par rapport à une utilisation normale, probablement, pour peu que l'horloge système soit à l'heure. S'il y a des considérations de sécurité, c'est plus risqué, en particulier parce qu'un utilisateur peut fixer le mtime à sa guise.
Paul Gaborit
À (at) 25 Nov 2009 10:56:55 GMT, Nicolas George <nicolas$ écrivait (wrote):
PIGUET Bruno wrote in message <heiv3q$pep$:
Le critère sur le triplet (stat.st_dev, stat.st_ino et stat.st_mtime) vous semble-t'il robuste pour ce genre d'opération ?
Ça dépend par rapport à quel genre de modifications. Par rapport à une utilisation normale, probablement, pour peu que l'horloge système soit à l'heure. S'il y a des considérations de sécurité, c'est plus risqué, en particulier parce qu'un utilisateur peut fixer le mtime à sa guise.
Sans aller chercher l'utilisateur malicieux, il y a aussi le problème de certains couples client/serveur NFS qui gardent (gardaient?) en cache trop longtemps ce genre d'information.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) 25 Nov 2009 10:56:55 GMT,
Nicolas George <nicolas$george@salle-s.org> écrivait (wrote):
PIGUET Bruno wrote in message <heiv3q$pep$1@sxcom1.cnrm.meteo.fr>:
Le critère sur le triplet (stat.st_dev, stat.st_ino et stat.st_mtime)
vous semble-t'il robuste pour ce genre d'opération ?
Ça dépend par rapport à quel genre de modifications. Par rapport à une
utilisation normale, probablement, pour peu que l'horloge système soit à
l'heure. S'il y a des considérations de sécurité, c'est plus risqué, en
particulier parce qu'un utilisateur peut fixer le mtime à sa guise.
Sans aller chercher l'utilisateur malicieux, il y a aussi le problème
de certains couples client/serveur NFS qui gardent (gardaient?) en
cache trop longtemps ce genre d'information.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) 25 Nov 2009 10:56:55 GMT, Nicolas George <nicolas$ écrivait (wrote):
PIGUET Bruno wrote in message <heiv3q$pep$:
Le critère sur le triplet (stat.st_dev, stat.st_ino et stat.st_mtime) vous semble-t'il robuste pour ce genre d'opération ?
Ça dépend par rapport à quel genre de modifications. Par rapport à une utilisation normale, probablement, pour peu que l'horloge système soit à l'heure. S'il y a des considérations de sécurité, c'est plus risqué, en particulier parce qu'un utilisateur peut fixer le mtime à sa guise.
Sans aller chercher l'utilisateur malicieux, il y a aussi le problème de certains couples client/serveur NFS qui gardent (gardaient?) en cache trop longtemps ce genre d'information.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
xavier
Paul Gaborit wrote:
Sans aller chercher l'utilisateur malicieux, il y a aussi le problème de certains couples client/serveur NFS qui gardent (gardaient?) en cache trop longtemps ce genre d'information.
On peut contourner ceci en calculant un Hash MD5 du fichier. Mais ça dépend des performances que l'OP attend. Si c'est plus long de calculer une somme de contrôle que de relire le fichier, on n'y gagne pas vraiment...
-- XAv Disponible au 01/06/2010 <http://www.xavierhumbert.net/perso/CV2.html>
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Sans aller chercher l'utilisateur malicieux, il y a aussi le problème
de certains couples client/serveur NFS qui gardent (gardaient?) en
cache trop longtemps ce genre d'information.
On peut contourner ceci en calculant un Hash MD5 du fichier. Mais ça
dépend des performances que l'OP attend. Si c'est plus long de calculer
une somme de contrôle que de relire le fichier, on n'y gagne pas
vraiment...
--
XAv
Disponible au 01/06/2010
<http://www.xavierhumbert.net/perso/CV2.html>
Sans aller chercher l'utilisateur malicieux, il y a aussi le problème de certains couples client/serveur NFS qui gardent (gardaient?) en cache trop longtemps ce genre d'information.
On peut contourner ceci en calculant un Hash MD5 du fichier. Mais ça dépend des performances que l'OP attend. Si c'est plus long de calculer une somme de contrôle que de relire le fichier, on n'y gagne pas vraiment...
-- XAv Disponible au 01/06/2010 <http://www.xavierhumbert.net/perso/CV2.html>
JKB
Le 25-11-2009, ? propos de Re: test robuste de détection de non-changemeùnt de fichier ?, Xavier ?crivait dans fr.comp.os.unix :
Paul Gaborit wrote:
Sans aller chercher l'utilisateur malicieux, il y a aussi le problème de certains couples client/serveur NFS qui gardent (gardaient?) en cache trop longtemps ce genre d'information.
On peut contourner ceci en calculant un Hash MD5 du fichier. Mais ça dépend des performances que l'OP attend. Si c'est plus long de calculer une somme de contrôle que de relire le fichier, on n'y gagne pas vraiment...
Et comment je calcule la somme de contrôle _sans_ relire le fichier ?
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 25-11-2009, ? propos de
Re: test robuste de détection de non-changemeùnt de fichier ?,
Xavier ?crivait dans fr.comp.os.unix :
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Sans aller chercher l'utilisateur malicieux, il y a aussi le problème
de certains couples client/serveur NFS qui gardent (gardaient?) en
cache trop longtemps ce genre d'information.
On peut contourner ceci en calculant un Hash MD5 du fichier. Mais ça
dépend des performances que l'OP attend. Si c'est plus long de calculer
une somme de contrôle que de relire le fichier, on n'y gagne pas
vraiment...
Et comment je calcule la somme de contrôle _sans_ relire le fichier ?
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 25-11-2009, ? propos de Re: test robuste de détection de non-changemeùnt de fichier ?, Xavier ?crivait dans fr.comp.os.unix :
Paul Gaborit wrote:
Sans aller chercher l'utilisateur malicieux, il y a aussi le problème de certains couples client/serveur NFS qui gardent (gardaient?) en cache trop longtemps ce genre d'information.
On peut contourner ceci en calculant un Hash MD5 du fichier. Mais ça dépend des performances que l'OP attend. Si c'est plus long de calculer une somme de contrôle que de relire le fichier, on n'y gagne pas vraiment...
Et comment je calcule la somme de contrôle _sans_ relire le fichier ?
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
xavier
JKB wrote:
Et comment je calcule la somme de contrôle _sans_ relire le fichier ?
Je me disais bien qu'il y avait un défaut :-)
Néanmoins, je crois que c'est un truc qui se trouve dans les métadonnées ZFS si tu l'utilises.
-- XAv Disponible au 01/06/2010 <http://www.xavierhumbert.net/perso/CV2.html>
JKB <knatschke@koenigsberg.fr> wrote:
Et comment je calcule la somme de contrôle _sans_ relire le fichier ?
Je me disais bien qu'il y avait un défaut :-)
Néanmoins, je crois que c'est un truc qui se trouve dans les métadonnées
ZFS si tu l'utilises.
--
XAv
Disponible au 01/06/2010
<http://www.xavierhumbert.net/perso/CV2.html>
Et comment je calcule la somme de contrôle _sans_ relire le fichier ?
Je me disais bien qu'il y avait un défaut :-)
Néanmoins, je crois que c'est un truc qui se trouve dans les métadonnées ZFS si tu l'utilises.
-- XAv Disponible au 01/06/2010 <http://www.xavierhumbert.net/perso/CV2.html>
JKB
Le 25-11-2009, ? propos de Re: test robuste de détection de non-changemeùnt de fichier ?, Xavier ?crivait dans fr.comp.os.unix :
JKB wrote:
Et comment je calcule la somme de contrôle _sans_ relire le fichier ?
Je me disais bien qu'il y avait un défaut :-)
Néanmoins, je crois que c'est un truc qui se trouve dans les métadonnées ZFS si tu l'utilises.
Donc c'est portable ;-)
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 25-11-2009, ? propos de
Re: test robuste de détection de non-changemeùnt de fichier ?,
Xavier ?crivait dans fr.comp.os.unix :
JKB <knatschke@koenigsberg.fr> wrote:
Et comment je calcule la somme de contrôle _sans_ relire le fichier ?
Je me disais bien qu'il y avait un défaut :-)
Néanmoins, je crois que c'est un truc qui se trouve dans les métadonnées
ZFS si tu l'utilises.
Donc c'est portable ;-)
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 25-11-2009, ? propos de Re: test robuste de détection de non-changemeùnt de fichier ?, Xavier ?crivait dans fr.comp.os.unix :
JKB wrote:
Et comment je calcule la somme de contrôle _sans_ relire le fichier ?
Je me disais bien qu'il y avait un défaut :-)
Néanmoins, je crois que c'est un truc qui se trouve dans les métadonnées ZFS si tu l'utilises.
Donc c'est portable ;-)
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
