Il y en a beaucoup en fait.
-
SparkleShare (deps : git/subversion, mono, Python) chez github Logiciel de synchronisation basé sur une interface graphique.
a. Versioning : par un système de contrôle de source, donc basé sur mutex sur un serveur central par un numéro de version.
b. État : en cours de développement
c. Pour : OSS, basé sur mono donc facilement moddable, Contre : processus au niveau de l'utilisateur, dépendant de GC, protocole de partage inefficace par ordre de grandeur car git est principalement pour les petits fichiers texte, assez difficile à compiler (j'ai essayé). Utilisation d'outils de haut niveau.
-
lipsync (deps : Unison, rsync) Logiciel basé sur les services en ligne de commande.
a. Versioning : par le biais du Algorithme delta de rsync . Je suppose que le programmeur doit choisir la résolution du conflit.
b. État : Je ne peux pas trouver son code source, donc je n'en ai aucune idée. Les seules choses dans son git repo sont des binaires.
c. Pour : belle installation, utilisant des outils de niveau intermédiaire.
-
iFolder - La Dropbox de Novell. Je n'ai pas encore étudié sa source. Je veux juste en finir avec ce montage et si les gens sont intéressés, j'en ajouterai d'autres.
a. Versioning :
b. État : Il est difficile de le faire compiler sur Ubuntu, sans parler des paquets. Voici un guide d'installation détaillé .
c. Pour : Client Windows X64, mature, intégration AD avec ACLs, fonctionnalités qu'aucun autre projet n'a commencé à mettre en œuvre. Je pense que cela pourrait être un bon point de départ. Contre : Novell pourrait ne pas utiliser son repo svn public comme repo principal et ne faire que des dépôts de code. Je ne sais pas exactement ce qu'il en est. Peut être trop couplé à openSUSE pour être facilement installé sur Ubuntu. Pour vérifier ses algorithmes.
-
scp/rcp - déprécié en faveur de rsync
-
DRDB - outils de mise en miroir de périphériques de blocs pour RAID-1 distribué, c'est-à-dire une variante serveur de dropbox. Je n'ai pas encore vérifié son code source, mais c'est uniquement sous linux. L'algorithme actuel serait probablement facile à combiner avec le code source dans mes réflexions en dessous de cette liste de logiciels.
a. Versioning : format de message interne sur LAN/WAN
b. État : semble assez mature
c. Pour : assez stable pour linux, Contre : aucun autre système d'exploitation n'est supporté
En ce moment, je cherche à améliorer les temps de compilation sur un Windows 7 virtualisé, où le temps de compilation sur un Windows 7 sur métal est de 40 s, mais virtualisé environ 3m 20s. Je pense écrire un pilote ioctl qui est un cache en écriture qui ressemble à un disque RAM pour les dossiers sélectionnés sur NTFS.
En utilisant les logiciels ci-dessus, je pense qu'une semaine de développement à plein temps par 2 ou 3 personnes produirait un Alpha utilisable qui ne vous fait pas perdre de fichiers en combinant les logiciels ci-dessus.
Sur mon système, l'idée générale serait donc la suivante ;
-
Montez un lecteur virtuel \?{GUID}, qui est le disque RAM et le cache RW. Le logiciel qui crée ce lecteur virtuel prend deux paramètres d'entrée (qui sont vitaux) :
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 les entrées-sorties. 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 être votre serveur de fichiers utilisant SAMBA/SMB.
b. Le chemin du dossier à monter, par ex. C:\ramdisk
Ce code pour la création de volumes virtuels est tiré de Le code de TrueCrypt dans /Driver/DriverFilter.c (parmi d'autres fichiers)
-
Le lecteur utilise SMB/le protocole VMWare/réseau pour récupérer des données au démarrage ; il récupère avec une faible priorité de tâche, de manière asynchrone depuis le réseau et remplit son cache. Il pourrait utiliser un algorithme de compactage simple et avoir un thread qui utilise le passage de continuation de type boîte à messages pour obtenir de bonnes performances. Sous Windows, il pourrait utiliser les appels d'entrée/sortie asynchrones normaux, et sous Linux, il pourrait utiliser la fonction epoll / inotify et prendre le code de nginx .
-
Mon service qui est le ram-disk monte le lecteur ramdisk sans nom comme un dossier NTFS. Tous les programmes peuvent continuer à écrire sur C:\ramdisk ou peu importe comment je l'appelle.
-
La copie asynchrone depuis le réseau continue. Avec un taux de lecture d'environ 100 MiB/s et un disque RAM de 2 GiB, il faudrait 20,5 s pour lire toutes les données.
Chaque appel à la lecture effectuerait un calcul dans le CPU de l'index dans un tableau fixe de taille maximale de n:ulong GiB. Cela nécessiterait une résolution des conflits ou des verrous de lecture-écriture. Si nous mettons en œuvre un algorithme de résolution des conflits comme ceux disponibles dans Microsoft Sync, nous pourrions transmettre chaque morceau en conflit comme un message à un autre processus de résolution des conflits. Dropbox résout ce problème en créant un nouveau fichier et en le nommant "PrevFileName Username's Conflicted Copy (yyyy-MM-dd).ext". Peut-être que cela pourrait être modifié par un petit widget, si l'on compile contre cette source unique -- le widget détecterait les changements en cours comme des messages/événements et choisirait le protocole de résolution de conflit. Ainsi, lors de la programmation contre un dossier en mode exclusif, la VM Windows pourrait régler le widget sur 'exclusif'.
Cela aurait les avantages suivants
- Il serait non bloquant / asynchrone.
- Cela supposerait, sans l'exiger, qu'un ordinateur écrive principalement dans les fichiers.
- Cela fonctionnerait pour des fichiers de taille arbitraire
- Il fonctionnerait sur *nix et Windows en reliant les projets mentionnés.
- Il fonctionnerait lorsque des performances de lecture élevées sont nécessaires (c'est-à-dire lorsque les fichiers sont physiquement situés sur le disque).
- Lorsque les événements conflictuels sont atteints, on pourrait fournir une application d'interface utilisateur qui permet à l'utilisateur d'écrire/de télécharger des plugins qui agissent sainement pour différents types d'événements -- c'est-à-dire différents types de fichiers. Par exemple, un fichier texte pourrait être affiché avec Kompare/WinDiff, tandis qu'un fichier binaire serait dupliqué et enregistré dans un autre fichier.