PureBasic

J'ai commencé un tout petit utilitaire de synchronisation de document entre ordinateur, car je n'aime pas avoir mon boulot en version différentes sur plusieurs pc, et j'aime faire les choses moi.

Ma question est : comment feriez vous pour distinguer les fichiers à mettre à jour sur chaque pc ?

j'ai utilisé un test MD5 sur chaque fichier, et il me reste à coder la partie comparaison.
le pb de cette méthode est que si le fichier est modifié et renommé, le programme ne pourras pas le reconnaitre, et en conséquence va le traiter comme un nouveau fichier (et proposer la suppression de l'ancien qui n'a plus d'équivalent - arf, c'est le fonctionnement que je veux ça -_-).

enfin, mis à part ce soucis là. vos idée, méthodes ? (le MD5 ou CRC32 c'est long quand même, l'objectif est de pouvoir traiter environ 2G de donnée en moins de 1min max)

J'aime assez le MD5 de part sa simplicité.
Pour ce qui est de comparer les fichiers, s'ils ne s'appellent pas de la même manière d'un pc à l'autre, c'est chercher la petite bête.
Je serai toi je couplerai MD5/ date de la dernière modification (doit bien avoir de l'API pour récupérer cette date vu qu'elle est dans l'explorer).

J'vais peut etre encore dire une connerie, mais en les chargeant un a un en mémoire et un CompareMemory() ?

Ar-S a écrit : Je serai toi je couplerai MD5/ date de la dernière modification (doit bien avoir de l'API pour récupérer cette date vu qu'elle est dans l'explorer).

perso j'avais utilisé juste la Date/heure/minute/seconde
et je gardais le plus récent !!

ça marchait pas trop mal ..

Je pense comme Dobro que l'heure est la façon la plus rapide de savoir quels sont les fichiers modifiés, de façon à EVITER la comparaison qui est une opération lourde et lente ! La vitesse est vraiment cruciale. Faire les MD5 de cent fichiers d'1Go, c'est l'horreur, tu peux aller te prendre un café. L'heure a aussi l'avantage d'être automatiquement modifiée par l'OS. Par contre, il faut s'assurer que l'heure est la même sur les deux places. Ce serait bien aussi de proposer la comparaison en option, comme dans tous les bons gestionnaires de fichiers.

j'utilisais cette procedure pour tester la date d'un fichier
(elle n'est pas de moi.... je sais plus ou je l'ai piqué... c'est peut etre aussi un aglomérat de divers Procedures glanées ...)

Fichier$= chemin+fichier a tester
Typedate.l= 1 => renvoi la date de création
Typedate.l=2 => renvoi la date du dernier acces
si typedate = autre chose que 1 ou 2 ; renvoi automatiquement la date de modification

Code : Tout sélectionner

Procedure.s FileTime(fichier$, typedate.l)
  TailleFichier = FileSize(fichier$)
  If TailleFichier >=0 ; teste si le fichier existe
    HandleFichier.l = OpenFile(2, fichier$); recupère le Handle du fichier avec la fonction OpenFile
  Else
    HandleFichier = 0
  EndIf
  If HandleFichier And OpenLibrary(0, "kernel32.dll")
    CallFunction(0, "GetFileTime", HandleFichier, ct.FILETIME, lat.FILETIME, lwt.FILETIME);
    Select typedate
      Case 1; si typedate = 1, renvoi la date de création
        CallFunction(0, "FileTimeToLocalFileTime", @ct, @lpLocalFileTime.FILETIME);pour prendre en compte l'heure d'été et d'hiver
      Case 2; si typedate = 2, renvoi la date du dernier accès
        CallFunction(0, "FileTimeToLocalFileTime", @lat, @lpLocalFileTime.FILETIME);pour prendre en compte l'heure d'été et d'hiver
      Default; si typedate = autre chose, renvoi automatiquement la date de modification
        CallFunction(0, "FileTimeToLocalFileTime", @lwt, @lpLocalFileTime.FILETIME);pour prendre en compte l'heure d'été et d'hiver
    EndSelect
    CallFunction(0, "FileTimeToLocalFileTime", @lwt, @lpLocalFileTime.FILETIME);pour prendre en compte l'heure d'été et d'hiver
    CallFunction(0, "FileTimeToSystemTime", @lpLocalFileTime, @st.SYSTEMTIME);pour convertir la date dans le format systemtime
    DateFichier$ = Space(256)
    HeureFichier$ = DateFichier$
    GetDateFormat_(2048, 0, @st, "dd'/'MM'/'yyyy", @DateFichier$, 254); donne la dte du fichier
    GetTimeFormat_(2048, #TIME_FORCE24HOURFORMAT, @st, 0, @HeureFichier$, 254); donne l'heure du fichier
    DateFichier$ = DateFichier$ + "  " + HeureFichier$; on assemble l'année et l'heure
    CloseFile(2)
    ProcedureReturn DateFichier$; renvoi la date du fichier
  Else
    ProcedureReturn "?"
  EndIf
EndProcedure

Pas essayé mais excellent Dobro

je pompe !

Et pourquoi pas tout simplement DirectoryEntryDate() et GetFileDate() de la bibliothèque FileSystem de PB ?

probablement qu'a l'epoque ou j'ai utilisé cette fonction
ça n'existait pas dans purebasic

du reste la fonction donne la date du dernier acces au fichier...

merci pour vos réponses,

@mesa, tu m'as devancé ^^

je pensais en effet n'utiliser que la date, et puis j'ai vu qu'il existe des fonctions dans PB pour les modifier.
Alors je me suis demandé si tout les logiciels modifiaient les dates.
Ensuite, la date de dernière accès doit certainement correspondre à un accès du disque qui n'arrive que lors de la création, car lors d'une modification, elle ne change pas.
(dommage)

@djes : comme je l'ai dis, je situ les besoins que doit traiter le prog dans les 2G de données. La MD5 reste raisonnable (d'après mes tests, mais il faudra que je test sur un pc moins rapide).

le principe est que tu bosses pdt la journée avec ton petit pc, puis le soir, tu lance la synchro, et tu bosses sur le gros, puis tu sync avec le petit.
ou bien de temps en temps tu sauves ton boulot sur le gros.

@KKC : bcp trop long je pense. surtout si tu compares chaque fichiers avec chaque autre.

avec mon système, je détecte les fichiers qui ont changé de répertoire. Mais je me demandais si c'est pas plus simple de supprimer celui qu'on ne trouve plus, et de copier (par réseau) celui qui est nouveau ??

pour mon synchroniseur (voir sur mon site), j'utilise GetFileDate( pour récupérer la date de dernière modification, cela fonctionne très bien

Et pour comparer les dates, j'ai ce script :

La variable Sync_Fat32_NTFS permet d'activer la compatibilité entre NTFS et FAT32

Code : Tout sélectionner

Procedure CompareFileTime(Date1, Date2)
	Protected Date12
	If Sync_Fat32_NTFS
		Date12 = Date1 - Date2
		If Date12 <= 2 And Date12 >= -2
			ProcedureReturn 0
		ElseIf Date1 > Date2
			ProcedureReturn 1
		Else
			ProcedureReturn -1
		EndIf
	Else
		If Date1 = Date2
			ProcedureReturn 0
		ElseIf Date1 > Date2
			ProcedureReturn 1
		Else
			ProcedureReturn -1
		EndIf
	EndIf
EndProcedure

Tu pourrais surveiller le dossier cf http://forums.purebasic.com/english/vie ... =5&t=47616

Parfait Droopy ,; )
Je vais finir mon truc de comparaison normal, puis ajouter la surveillance des dossiers. (comme ça tu peux synchro avec plusieurs cas de figures -> plantage par ex)

@Lsi : j'imagine que le FAT32 ou le ntfs n'est précis qu'à 2sec prés ?

oui, le FAT32 est à 2s près, mais le NTFS est à la seconde

Bonjour,

pour mon travail ( je suis administrateur système), j'ai cherché un programme de comparaison de fichier ( 500Go et 500k fichiers ).

le plus rapide que j'ai trouvé fonctionnait de la manière suivante :

Tri en fonction de la taille : si 2 fichiers ne font pas la même taille, ils ne peuvent pas être identique.
Comparaison bit à bit des fichiers ayant la même taille : Avec le checksum MD5, tu es obligé de parcourir le fichier en entier, avec cette méthode, des que tu tombes sur une différence tu sais qu'ils ne sont pas identiques. tu peux gagner énormément de temps.

Dans ton cas, ça peut être utile, mais ce n'est pas le mieux. Si tu veux synchroniser entre des pc avec des connexions un peu lente, il y a plus de chose a prendre en compte :

Minimiser les données à transférer : c'est une problématique qui existe depuis qu'on a relié des ordinateurs entre eux, l’algorithme de rsync que tu peux trouver sur la page wikipédia est très intéressant a étudier.
Définir le sens de synchronisation : le plus compliqué a mettre en place étant le multidirectionnel, regarde les problèmes que rencontre le client de synchronisation owncloud.

la surveillance des dossiers est une très bonne idées, cela te permet de mettre en route la synchronisation dés qu'il y a une action: le plus long étant la copie de données en local et encore plus en distant.

Basé la comparaison de fichier sur des attributs non fiables est une mauvaise idées :

Date et heure : Windows a un comportement bien a lui, et surtout différent, entre la copie et le déplacement de fichier.
Nom de fichier : un renommage d'un fichier de 2Go et c'est la fête au village.

Si je devais faire une application de ce genre, j'utiliserai ces pistes :

Faire une liste des fichiers source,
Faire une cheksum partielle de chaque fichiers, voir suivant la taille si il ne vaut pas mieux de faire une cheksum totale
Faire une liste des fichiers destination,
faire le même cheksum que pour la source
Chercher si des fichiers sont renommé/déplacé : utilisation du nom/chemin des fichiers et checksum.
Faire les actions : renommage/déplacement/copie des fichiers distant, copie partielle ou totale des fichiers modifié, avec un peu de compression peut etre.
Faire une base de donnée avec les informations importante afin d'optimiser les opérations lors de la prochaine synchronisation.
Vérifier si tout est bien fait.

pour le transport de fichier sur réseau je passerai par du HTTP(S), ça évite d’être embêter par les firewall ultra restritif.
C'est juste une ébauche, qui prend en compte les problèmes que j'ai rencontré au quotidien dans mon travail.

Si tu veux avoir plus d'informations, regarde les logiciels existant, style synchroniseur et sauvegarde.
Même un logiciel du style supercopier, peut t'apporter des choses.

++ et bon courage

PureBasic

Prog de synchro

Prog de synchro

Re: Prog de synchro

Re: Prog de synchro

Re: Prog de synchro

Re: Prog de synchro

Re: Prog de synchro

Re: Prog de synchro

Re: Prog de synchro

Re: Prog de synchro

Re: Prog de synchro

Re: Prog de synchro

Re: Prog de synchro

Re: Prog de synchro

Re: Prog de synchro

Re: Prog de synchro