je ne vois pas en quoi cela mettrait à mal la sécurité, pourquoi un rafraîchissement partiel serait plus propice à des "loupés"
Si l'on se place dans le cadre d'une mise à jour partielle d'un blog, l'on n'aura que peu de fichiers à transférer vers le répertoire du serveur (environ 2 ou 3). Et d'une manière générale, toute modification sera systématiquement l'ajout ou la modification d'un billet existant. Dans ce cas, au fur et à mesure que le blog grossi, on pourra faire ce transfert manuellement soit en copiant en vrac la totalité des fichiers si le répertoire du serveur est sur la même machine que le moteur de blog soit en les transférant vers le répertoire de l'hébergeur. Il y a deux possibilités alors : rsync ou ftp. Mais certains hébergements n'ont que ftp. Alors il semble évident de ne transférer que la poignée de fichiers modifiés. C'est absolument sans inconvénient tant que l'on ajoute ou que l'on modifie un billet.
Comme la routine de la mise à jour du blog devient une seconde nature, lors du cas exceptionnel d'une suppression de billet, s'il agit comme d'habitude l'utilisateur peut oublier d'enlever le billet incriminé résidant sur le répertoire du serveur. Ou se tromper dans la suppression du fichier car mon système de nommage n'est absolument pas fait pour les humains (une suite de chiffres).
En ne conservant qu'une seule procédure de mise à jour, la procédure de transfert sera la même qu'elle que soit le nombre de billets ajoutés ou supprimés. Et les fichiers auront tous la même date ce qui rend encore plus délicat de savoir ceux qui ont été réellement modifiés ou pas. Le plus simple sera donc de procéder par wagon entier pour les transferts. (Par exemple, mon hébergeur conseille d'uploader une tarball plutôt que les fichiers individuellement.) Dans ce cas, on videra le répertoire du serveur et l'on y éclatera une tarball. Ce qui veut dire que le blog mis à nouveau en ligne sera complètement clean que l'on ait fait une mise à jour anodine ou critique.
Une autre possibilité serait de lier symboliquement le répertoire du serveur sur celui d'export du moteur de blog si les deux résident sur la même machine (ou de faire un montage NFS sur un serveur distant ?).
Tout ceci peut sembler paranoïaque mais, faisant parti des gens que l'on peut qualifier de "tête en l'air", je sais qu'il existe un risque sérieux et réel lors d'une suppression de billet. Et je sais aussi que les conséquences sociales peuvent être lourdes.
[^] # Re: Oui, mais c'est pas forcément le bon outil
Posté par Denis Bernard . En réponse à la dépêche Moteur de blog fBlog. Évalué à 2.
Si l'on se place dans le cadre d'une mise à jour partielle d'un blog, l'on n'aura que peu de fichiers à transférer vers le répertoire du serveur (environ 2 ou 3). Et d'une manière générale, toute modification sera systématiquement l'ajout ou la modification d'un billet existant. Dans ce cas, au fur et à mesure que le blog grossi, on pourra faire ce transfert manuellement soit en copiant en vrac la totalité des fichiers si le répertoire du serveur est sur la même machine que le moteur de blog soit en les transférant vers le répertoire de l'hébergeur. Il y a deux possibilités alors : rsync ou ftp. Mais certains hébergements n'ont que ftp. Alors il semble évident de ne transférer que la poignée de fichiers modifiés. C'est absolument sans inconvénient tant que l'on ajoute ou que l'on modifie un billet.
Comme la routine de la mise à jour du blog devient une seconde nature, lors du cas exceptionnel d'une suppression de billet, s'il agit comme d'habitude l'utilisateur peut oublier d'enlever le billet incriminé résidant sur le répertoire du serveur. Ou se tromper dans la suppression du fichier car mon système de nommage n'est absolument pas fait pour les humains (une suite de chiffres).
En ne conservant qu'une seule procédure de mise à jour, la procédure de transfert sera la même qu'elle que soit le nombre de billets ajoutés ou supprimés. Et les fichiers auront tous la même date ce qui rend encore plus délicat de savoir ceux qui ont été réellement modifiés ou pas. Le plus simple sera donc de procéder par wagon entier pour les transferts. (Par exemple, mon hébergeur conseille d'uploader une tarball plutôt que les fichiers individuellement.) Dans ce cas, on videra le répertoire du serveur et l'on y éclatera une tarball. Ce qui veut dire que le blog mis à nouveau en ligne sera complètement clean que l'on ait fait une mise à jour anodine ou critique.
Une autre possibilité serait de lier symboliquement le répertoire du serveur sur celui d'export du moteur de blog si les deux résident sur la même machine (ou de faire un montage NFS sur un serveur distant ?).
Tout ceci peut sembler paranoïaque mais, faisant parti des gens que l'on peut qualifier de "tête en l'air", je sais qu'il existe un risque sérieux et réel lors d'une suppression de billet. Et je sais aussi que les conséquences sociales peuvent être lourdes.