Il y en a en fait beaucoup.
-
SparkleShare (deps: git / subversion, mono, python) à github
Logiciel de synchronisation basé sur une interface graphique.
a Versionnage: via un système de contrôle de source, il est donc basé sur un serveur central via un numéro de version.
b. Etat: en développement
c. Avantages: OSS, mono-modulaire si facilement modulable, Inconvénients: processus au niveau utilisateur, dépendant du GC, protocole de partage inefficace par ordre de grandeur car git est principalement destiné aux petits fichiers texte, assez difficile à compiler (j'ai essayé). Utiliser des outils de haut niveau.
-
lipsync (deps: Unison, rsync)
Logiciel basé sur un service en ligne de commande.
a Gestion des versions: via le algorithme rsync delta . Je suppose que le programmeur doit choisir la résolution de conflit.
b. Etat: Je ne trouve pas son code source, donc je n'en ai aucune idée. Les seules choses de son dépôt git sont des binaires.
c. Avantages: bonne configuration, utilisation d’outils de niveau intermédiaire.
-
iFolder - Dropbox de Novell.
Je n'ai pas encore étudié sa source. Je veux juste avoir cette édition avec et si les gens sont intéressés, j'ajouterai plus.
a Versionnage:
b. Etat: Problématique à obtenir pour compiler même sur Ubuntu, sans parler des paquets. Voici un guide d'installation détaillé .
c. Avantages: client Windows X64, mature, intégration AD avec ACL, fonctionnalités qu'aucun autre projet n'a commencé à implémenter. Je pense que cela pourrait être un bon point de départ. Inconvénients: Novell pourrait ne pas utiliser son dépôt public svn comme référentiel principal et ne faire que des sauts de code. Je ne sais pas exactement à ce sujet cependant. Peut-être trop couplé à openSUSE pour s’installer facilement sur Ubuntu. Pour vérifier ses algorithmes.
-
scp / rcp - déconseillé en faveur de rsync
-
DRDB : bloque les outils de mise en miroir des périphériques pour RAID-1 distribué, c'est-à-dire une variante de serveur de la boîte de dépôt. Je n'ai pas encore vérifié son code source, mais ce n'est que Linux. L'algorithme actuel serait probablement facile à combiner avec le code source dans mes réflexions ci-dessous.
a Versionnage: format de message interne sur LAN / WAN
b. Etat: semble assez mature
c. Avantages: assez stable pour Linux, Inconvénients: aucun autre système d'exploitation n'est pris en charge
En ce moment, j'étudie l'amélioration des temps de compilation sur un Windows 7 virtualisé, où la compilation sur un Windows 7 en métal est de 40 s, mais virtualisée sur environ 3 m 20. Je pense à écrire un pilote ioctl qui est un cache en écriture qui ressemble à un disque virtuel pour les dossiers sélectionnés sur NTFS.
En utilisant le logiciel ci-dessus, je pense qu'une semaine de développement à temps plein de 2-3 personnes produirait un Alpha utilisable qui ne perdrait pas vos fichiers en combinant les logiciels ci-dessus.
Sur mon système alors, l’idée générale serait:
-
Montez un lecteur virtuel \? {GUID}, c’est-à-dire le disque virtuel et le cache RW. Le logiciel créant ce lecteur virtuel prend deux paramètres d'entrée (qui sont essentiels):
a Le dossier cible; Il s'agit du dossier SMB. Je vais donc laisser la pile réseau du système d'exploitation gérer le véritable IO. Dans mon cas, il s’agit du dossier virtuel VMWare, qui a lui-même une cible sur un lecteur ext4, mais il pourrait facilement s'agir de votre serveur de fichiers utilisant SAMBA / SMB.
b. Le chemin du dossier à monter, par ex. C: \ ramdisk
Ce code de création de volumes virtuels est issu du code TrueCrypt , dans /Driver/DriverFilter.c (entre autres fichiers)
-
Le lecteur utilise le protocole SMB / VMWare / network pour récupérer des données au démarrage; il récupère avec une priorité de tâche basse, de manière asynchrone à partir du réseau et remplit son cache. Il pourrait utiliser un algorithme de compactage simple et avoir 1 thread qui utilise la continuation de type boîte de message pour obtenir de bonnes performances. Sous Windows, il pourrait utiliser les appels IO asynchrones normaux et sous Linux, il pourrait utiliser le epoll / inotify l'implémentation et prendre le code de nginx .
-
Mon service, à savoir le disque ram, monte le disque ramdisk non nommé en tant que dossier NTFS. Tous les programmes peuvent continuer à écrire sur C: \ ramdisk ou sur tout ce que j'appelle.
-
La copie asynchrone du réseau continue. Avec un taux de lecture d'environ 100 Mo / s et 2 Go de disque virtuel, il serait de 20,5 secondes pour lire toutes les données.
Chaque appel à lire effectuerait un calcul de l’index dans l’unité de traitement dans un tableau fixe de taille N: ulong GiB fixe. Cela nécessiterait une résolution de conflit, ou des verrous en lecture-écriture.Si nous implémentions un algorithme de résolution de conflits comme ceux disponibles via Microsoft Sync, nous pourrions transmettre chaque fragment en conflit comme un message à un autre processus de résolution de conflit. Dropbox le résout en créant un nouveau fichier et en le nommant "Copie en conflit du nom d'utilisateur de PrevFileName (aaaa-MM-jj) .ext". Peut-être cela pourrait-il être modifié à travers un petit widget, si l'on compile avec cette source unique - le widget détecterait les changements en suspens en tant que messages / événements et choisirait le protocole de résolution de conflit. En tant que tel, lors de la programmation sur un dossier en mode exclusif, la machine virtuelle Windows peut définir le widget sur «exclusif».
Cela aurait ces PRO
- Ce serait non-bloquant / asynchrone
- Cela supposerait, mais n’exige pas qu’un ordinateur écrit principalement dans les fichiers.
- Cela fonctionnerait pour des fichiers volumineux arbitrairement
- Cela fonctionnerait sur * nix et Windows en liant les projets mentionnés.
- Cela fonctionnerait lorsque des performances de lecture élevées sont nécessaires (c’est-à-dire que les fichiers sont physiquement situés sur le disque)
- Lorsque les événements en conflit sont atteints, il est possible de fournir une application d’interface utilisateur qui permet à l’utilisateur d’écrire / télécharger des plugins qui agissent en toute sécurité pour différents types d’événements - à savoir différents types de fichiers. Par exemple. Un fichier texte pourrait être créé avec Kompare / WinDiff, tandis qu'un fichier binaire serait dupliqué et enregistré sous un autre fichier.