2010-12-01 3 views
0

J'écris du code pour mettre à jour une application en récupérant de nouvelles DLL à partir d'un site ftp, selon un fichier manifest, également sur le site ftp, qui spécifie les versions de chaque DLL. L'idée de base est, qu'un programme de mise à jour s'exécute au démarrage, qui vérifie le manifeste sur le site ftp, télécharge toutes les DLL qui sont plus récentes que celles utilisées par l'application, puis démarre l'application et se ferme. Cela conduit au problème suivant, que je ne suis pas sûr de la meilleure façon de gérer: Dites que je veux mettre un nouveau dll sur le site ftp, mais en même temps une instance d'application de mise à jour essaie de lire cela dll. Si je supprime la DLL, puis copiez sur la nouvelle, le programme de mise à jour peut ne pas voir le fichier, même si le manifeste indique qu'il devrait être là. J'ai l'idée d'une sorte de fichier marqueur, qui servira d'objet de synchronisation, et dont l'existence I et l'instance de mise à jour peuvent servir de verrou, mais ne s'agit-il pas simplement de déplacer le problème? Il y a encore le temps entre vérifier si le verrou est là, et faire le verrou, dans lequel quelqu'un d'autre pourrait faire le verrou, et commencer à modifier les fichiers ftp. De plus, si un programme de mise à jour se bloque avant de supprimer le marqueur, il n'y a aucun moyen de savoir si le marqueur des restes doit être supprimé. Edit: J'ai également vu une suggestion pour télécharger les fichiers dans un autre dossier, puis renommer le dossier, puisque les renames sont supposées être une opération atomique dans ftp, mais est-il possible de simplement renommer le dossier au nom de un dossier existant? Le dossier existant ne devrait-il pas être supprimé en premier, causant ainsi le même problème?Synchronisation d'accès local/distant pour un site ftp

Existe-t-il une approche standard pour résoudre ce problème?

Répondre

1

Que diriez-vous de ceci: Sur le serveur FTP, incluez l'information de version dans le nom de fichier. Sur le client, renommez le fichier après le téléchargement.

+0

Merci. Je pense que ça pourrait marcher. Étant donné que le manifeste spécifie les versions dll à utiliser, il n'y a aucun inconvénient à avoir deux versions dll en même temps. Une fois les nouvelles DLL téléchargées, je copie le nouveau manifeste sur le site. Dans le chevauchement entre les versions, les clients devront comprendre, ce qui est la version la plus récente du manifeste, mais c'est bien sûr faisable. Je suppose que je tiens à quelque chose d'un peu plus simple, mais si aucune autre réponse ne vient, je vais accepter celle-ci. – Boris

+0

Il me vient à l'esprit que vous aurez toujours le même problème avec la mise à jour du manifeste, bien que vraisemblablement, il est beaucoup plus petit et donc le risque est plus petit. Peut-être que vous pourriez supprimer l'ancien manifeste, mettre à jour les nouvelles DLL, puis télécharger le nouveau manifeste. Tout client qui télécharge actuellement les anciennes DLL va continuer, et si un nouveau client trouve le manifeste manquant, il peut attendre et réessayer dans dix secondes ou quoi que ce soit. Et après avoir téléchargé le manifeste, le client pourrait vérifier la présence d'un marqueur de fin de fichier pour s'assurer qu'il est complet. –

+0

J'avais pensé à ça. Je ne pense pas, je devrais mettre à jour le manifeste. Au lieu de cela, le nom du manifeste doit également être versionné. Le client pourrait alors commencer par trouver le plus récent manifeste, puis le télécharger, et les DLL qui vont avec. Après un certain temps, disons une heure ou un jour, tous les clients qui avaient téléchargé l'ancien manifeste auraient téléchargé les anciennes DLL, et tous les téléchargements actuels ne seraient que des nouvelles versions, donc l'ancienne version pourrait être supprimée. Pour vous assurer que le nouveau manifeste est complètement téléchargé, je pourrais le créer sous un autre nom, puis faire un changement de nom. – Boris

Questions connexes