Discussion :

[mnssylvain]

Bonjour,

Je souhaite réaliser une sauvegarde des fichiers de donnée de mon appli sur un serveur.

Pour éviter d'uploader tous les fichiers je voudrais comparer les fichiers distant à ceux présent sur mon disque dur afin de savoir s'ils sont différents ou pas.

Pour le moment je compare les dates mais ça me pose des problèmes.... La date que je récupère pour les fichiers distants c'est la date de création sur le serveur alors que j'utilise la date de modification pour les fichiers locaux.
Du coup pour mes test j'ai mis des vieux fichiers sur le serveur mais si je les compare aux fichiers récents.... ça plante puisque les fichiers distants ont la date d'aujourd'hui.....

Je pensais éventuellement comparer la taille..... mais est ce qu'un fichier qui a la même taille est à coup sur identique.....

Merci de me faire partager votre expérience.

[Raptor92]

Bonsoir,

Je pensais éventuellement comparer la taille..... mais est ce qu'un fichier qui a la même taille est à coup sur identique.....

Je n'ai pas la réponse complète à votre problème, mais ce qui est sur, c'est que deux fichiers de même taille peuvent avoir des données complètement différentes.

D'ou une question: puisse qu'une sauvegarde n'est en fait que la masse de vos données à un instant "T", pourquoi ne pas remplacer vos fichiers "dit les plus anciens" par les nouveaux ?

Bonne soirée

[tatayo]

Bonjour,
Tu peux calculer le hash de tes fichiers (fonction hashfichier) et le stocker à côté d'eux (par exemple dans MonFichier.Hash). Ainsi pour savoir si tu dois sauvegarder tes fichiers, tu calcules le hash du fichier local et tu le compares avec le hash distant. Le hash te renvoyant une chaine somme toute de petite taille, son transfert sera transparent.

Tatayo.

[mnssylvain]

merci pour vos réponses,

pour Raptor92, le pb c'est que mes fichiers anciens sur le serveur sont considérés comme récents puisque envoyés récemment... Il faut donc attendre une modification de mes fichiers de données à une date plus récentes que celle de l'envoi.
Bon en pratique j'envoie les derniers fichiers sur le serveur..... donc ça devrait marcher mais le test que je viens de faire ne fonctionne pas et ça m'embête un peu

pour tatayo:
Je n'ai pas la fonction hash en WD10. j'aurai bientot la 15 et j'essayerai cette solution qui m'a l'air pas mal du tout si j'arrive à faire un hash du fichier distant.


En attendant j'ai essayé la fonction "fcompare" mais je n'arrive pas à lui faire prendre le chemin du fichier distant. J'essaie avec ftprepencour, il me renvoie bien l'adresse du répertoire sur le serveur FTP (/nomdurepdistant...) mais fcompare ne l'accepte pas.....
Je pense qu'il faudrait que je charge le fichier avant de le comparer... mais vu la taille des fichiers ça risque d'être long.....


Si vous avez d'autres idées je suis preneur
merci d'avance

[Raptor92]

Bonjour,

Je comprends bien votre problème concernant la date des fichiers, mais si vous optez pour une "sauvegarde classique", cela relève à dire que vous remplacez vos fichiers par d'autres.
Ce qui règlerais votre problèmes de tailles et dates.

Ce n'est qu'une idée bien sur
Bonne journée

[Bowen]

Heu, si la sauvegarde à lieu toujours à partir du même poste, il serait peut-être aussi simple de journaler localement les fichiers envoyés, ainsi que leurs tailles et dates d'upload.

[Raptor92]

Bonjour Bowen,

Heu, si la sauvegarde à lieu toujours à partir du même poste, il serait peut-être aussi simple de journaler localement les fichiers envoyés, ainsi que leurs tailles et dates d'upload.

mnssylvain avait l'air de parler de ficher distant, d'où mon idée de "sauvegarde" qui pourrait être également le remplacement des anciens par les nouveaux via FTP.
Mais si les fichiers à comparer se trouvent sur le même disque, alors j'imagine que votre solution doit être meilleure que la mienne

Bonne journée

[Bowen]

C'est le contraire Raptor92.
Si les fichiers sont sur le même disque, le temps de copie pour sauvegarde est très bref. Par contre si les fichiers sont sur un site distant (ce qui est souvent le cas lors d'un accès FTP), le mot "sauvegarde" prends alors tout son sens.
Par contre le temps d'upload est beaucoup plus long, et il devient intéressant de faire une sauvegarde incrémentielle (seulement les fichiers modifiés).
C'est pour ça que je proposais de stocker les dates et tailles des fichiers uploadés
Ensuite, à chaque nouvelle sauvegarde incrémentielle, uploader seulement les fichiers ayant une date de modif et/ou une taille différente de la dernière fois où on l'a uploadé.
Prévoir aussi une procédure de renvoi complet, à faire de temps en temps.

[mnssylvain]

bonjour,

oui c'est bien une sauvegarde d'un disque dur local sur lequel est installée l'application vers un serveur FTP.

Je peux effectivement remplacer tous les fichiers mais ça prends plus de temps que de remplacer que ceux qui ont changés.

Le but final c'est de proposer aux différents utilisateurs du logiciel de faire une sauvegarde sur un serveur FTP pour être sûr d'avoir une sauvegarde valide quelques part.

Je voudrais donc ensuite automatiser cette sauvegarde. Il faudrait pas lors de la réinstallation du logiciel par un client que les fichiers distants soient remplacés par ceux qui viennent d'être créer par l'installation (car plus récents d'après leurs dates).
Je pense que la solution de Bowen serait utile pour cette étape.
j'incrémente une valeur sur un fichier ini en local et sur le serveur. comme ça je sais que celui qui à la valeur la plus grande est le plus récent.

Qu'en pensez vous?
Merci pour vos réponses qui m'aide à avancer.

[Bowen]

Il faudrait pas lors de la réinstallation du logiciel par un client que les fichiers distants soient remplacés par ceux qui viennent d'être créer par l'installation (car plus récents d'après leurs dates).

Heu là tu m'inquiètes. Quel est le cas qui se présente chez toi ?

1. Les utilisateurs peuvent installer des versions locales de l'application, et avoir ainsi des données distinctes les uns des autres
2. Les utilisateurs peuvent installer des versions client de ton application, et les relier sur une base de données centrale donc commune à tous

Dans le premier cas, il faut une sauvegarde par utilisateur, donc plusieurs dossiers de destination.

Dans le second cas, il ne faut pas que tes utilisateurs puissent recréer des fichiers de données à vide, sinon les données existantes seraient définitivement perdues. (à fortriori si ils faisaient ça un jour où la sauvegarde n'a pas marché)

[tatayo]

Tu peux aussi stocker la date et la taille du fichier, au moment de sa sauvegarde, dans un fichier "annexe" sur le serveur FTP. Ainsi tu peux les comparer aux date/taille du fichier local.

Tatayo.

[mnssylvain]

Pour Bowen

Chaque utilisateur aura sa propre Base de données. Il me faudra donc un répertoire par utilisateur, c'est prévu.

Je vais bosser sur le stockage des informations des fichiers envoyés proposé par tatayo, ça me semble une bonne piste...

Merci je vous tiens au courant

Je vois à peu près comment écrire dans un fichier texte ou ini mais comment gérer la mise à jour de ce fichier en fonction des envois.... Peut être en le recréant à chaque fois à partir des fichiers locaux? Comment fais tu Tatayo?

[tatayo]

Pour Bowen

Je vois à peu près comment écrire dans un fichier texte ou ini mais comment gérer la mise à jour de ce fichier en fonction des envois.... Peut être en le recréant à chaque fois à partir des fichiers locaux? Comment fais tu Tatayo?

A chaque envois d'un fichier:
Tu télécharges le fichier d'infos, et tu lis la date et la taille et tu compares avec le fichier en cours.
Si au moins un des deux ne correspond pas, tu renvoie le fichier HF, note les date/tailles dans le fichier info et renvoie ce dernier sur le serveur.

Tatayo.

[Bowen]

J'ai bien l'impression que ça va finir par faire une usine à gaz...
Pourquoi, au lieu de stocker tes infos dans un fichier distant, tu ne les stockerais pas dans un fichier local au poste (un .fic HF quoi)
C'est beaucoup plus facile à lire, mais pour le reste ça fonctionne exactement pareil.
Sauf si tatayo voit un intérêt à stocker ce fichier en distant, il me semble que c'est exactement le même principe, avec un transfert de fichier en moins.
(je rappelle que selon mnssylvain, chaque utilisateur sauvegarde ses données dans un dossier séparé).

[tatayo]

Voilà pourquoi:

merci pour vos réponses,

pour Raptor92, le pb c'est que mes fichiers anciens sur le serveur sont considérés comme récents puisque envoyés récemment... Il faut donc attendre une modification de mes fichiers de données à une date plus récentes que celle de l'envoi.
Bon en pratique j'envoie les derniers fichiers sur le serveur..... donc ça devrait marcher mais le test que je viens de faire ne fonctionne pas et ça m'embête un peu

J'en ai conclu que la date des fichiers sur le serveur "n'est pas bonne", donc qu'il ne peut pas se baser dessus. D'où le stockage dans un fichier.
Ensuite pourquoi sur le serveur ? En fait j'étais resté dans l'idée du hash, et ce dernier sert surtout à vérifier l'intégrité d'un téléchargement, donc on le garde sur le serveur (et puis celà permet sur le serveur de connaitre la vrai date du fichier sauvegardé).
Mais sinon il est tout à fait possible de garder ces informations sur le poste client.

Tatayo.

[mnssylvain]

Merci pour ces réponses....

le problème de stocker ces infos en local c'est qu'en cas de crash... c'est perdu....
C'est ce qui est arrivé à un de mes clients....

[klbsjpolp]

Et pourquoi ne pas utiliser un utilitaire de sauvegarde qui fait tous tout seul du genre rsync ou rBackup?

[mnssylvain]

Pourquoi pas mais on peut le gérer à partir de windev sans que l'utilisateur n'ait rien à faire???

[klbsjpolp]

Ma solution n'implique pas que l'utilisateur fasse quoi que ce soit mais évite d'avoir des années de développement pour toi. Ce genre de système est très complexe et ce genre de projet peut facilement déraper. Ce n'est évidemment qu'une suggestion, je ne connais pas toutes les contraintes, les motivations et l'expérience de l'équipe.

[mnssylvain]

salut klbsjpolp

L'équipe se résume à moi et je suis hyper motivé. Je voudrais bien que tu m'aides à démarrer dans le pilotage de rsync à partir de Windev. Cette solution à l'air très très bien. C'est exactement ce dont j'aurais besoin.
Pour le moment j'ai réussi à coder une solution qui à l'air de fonctionner. Mais les possibilités offertes par rsync sont vraiment intéressantes.
Je vais commencer à me documenter.

en espérant que tu puisses m'aider..... merci d'avance