Ce ne sono in realtà molti.
-
SparkleShare (deps: git / subversion, mono, python) a github
Software di sincronizzazione basato su interfaccia grafica.
a. Controllo delle versioni: tramite un sistema di controllo del codice sorgente, quindi basato su mutex su un server centrale tramite un numero di versione.
b. Stato: in fase di sviluppo
c. Pro: OSS, mono-based così facilmente moddable, Contro: processo a livello utente, dipendente da GC, inefficace protocollo di condivisione di ordini di grandezza come git è principalmente per piccoli file di testo, abbastanza difficile da compilare (ho provato). Utilizzo di strumenti di alto livello.
-
lipsync (deps: Unison, rsync)
Software basato su servizi a riga di comando.
a. Controllo delle versioni: tramite rsync delta algorithm . Presumo che il programmatore debba scegliere la risoluzione dei conflitti.
b. Stato: non riesco a trovare il suo codice sorgente, quindi non ne ho idea. Le uniche cose nel suo repository git sono i binari.
c. Pro: bella configurazione, utilizzando strumenti di medio livello.
-
iFolder - Dropbox di Novell.
Non ho ancora studiato la sua fonte. Voglio solo ottenere questa modifica e se le persone sono interessate ne aggiungerò altre.
a. Versioning:
b. Stato: Problematico portarlo a compilare anche su Ubuntu, per non parlare dei pacchetti. Ecco una guida all'installazione dettagliata .
c. Pro: client Windows X64, maturo, integrazione AD con ACL, funzionalità che nessun altro progetto ha iniziato a implementare. Penso che questo potrebbe essere un buon punto di partenza. Contro: Novell potrebbe non utilizzare il repository svn pubblico come repository primario e fare solo code-drop. Non so esattamente di questo però. Potrebbe essere troppo accoppiato a openSUSE per installare facilmente su Ubuntu. Per verificare i suoi algoritmi.
-
scp / rcp - deprecato a favore di rsync
-
DRDB - blocca strumenti di mirroring del dispositivo per RAID-1 distribuito, ovvero una variante server di dropbox. Non ho ancora controllato il suo codice sorgente, ma è solo Linux. L'algoritmo attuale sarebbe probabilmente facile da combinare con il codice sorgente nelle mie riflessioni sotto questo elenco di software.
a. Controllo delle versioni: formato dei messaggi interni su LAN / WAN
b. Stato: sembra abbastanza maturo
c. Pro: abbastanza stabile per Linux, Contro: non sono supportati altri sistemi operativi
In questo momento sto studiando come migliorare i tempi di compilazione su un Windows 7 virtualizzato, dove i tempi di compilazione su Windows 7 su metallo sono 40 secondi, ma virtualizzati circa 3m 20s. Sto pensando di scrivere un driver ioctl che è una cache write-through che assomiglia a un ram-disk per le cartelle selezionate su NTFS.
Usando il software di cui sopra, penso che una settimana di sviluppo a tempo pieno di 2-3 persone produrrebbe un Alpha utilizzabile che non perderà i tuoi file combinando i software di cui sopra.
Quindi sul mio sistema, l'idea generale sarebbe;
-
Montare un'unità virtuale \? {GUID}, ovvero il ram-disk e la RW-cache. Il software che crea questo disco virtuale accetta due parametri di input (che sono fondamentali):
a. La cartella di destinazione; questa è la cartella SMB, quindi lascerò che lo stack di rete del sistema operativo gestisca l'IO effettivo. Nel mio caso questa è a sua volta la cartella virtuale VMWare, che ha in sé una destinazione su un'unità ext4, ma potrebbe facilmente essere il tuo file server utilizzando SAMBA / SMB.
b. Il percorso della cartella da montare, ad es. C: \ ramdisk
Questo codice per la creazione di volumi virtuali può essere preso dal codice di TrueCrypt , in /Driver/DriverFilter.c (tra gli altri file)
-
L'unità utilizza SMB / il protocollo VMWare / network per recuperare i dati all'avvio; recupera con una priorità bassa attività, in modo asincrono dalla rete e riempie la sua cache. Potrebbe utilizzare un semplice algoritmo di compattazione e disporre di 1 thread che utilizza la continuazione del tipo message-box per ottenere grandi prestazioni. Su Windows potrebbe utilizzare le normali chiamate IO asincrone e su linux potrebbe usare epoll / inotify implementazione e prendi il codice da nginx .
-
Il mio servizio che è il ram-disk monta l'unità ramdisk senza nome come una cartella NTFS. Tutti i programmi possono continuare a scrivere su C: \ ramdisk, o come lo chiamo io.
-
La copia asincrona dalla rete continua ancora. Con una velocità di lettura di circa 100 MiB / se 2 GB di ramdisk, sarebbero 20,5 secondi per leggere tutti i dati.
Ogni call to read eseguirà un calcolo della CPU dell'indice in un array di dimensione n: max GiB max fisso. Richiederebbe comunque la risoluzione dei conflitti o i blocchi di lettura-scrittura.Se implementassimo un algoritmo per la risoluzione dei conflitti come quelli disponibili tramite Microsoft Sync, potremmo passare ogni blocco che entra in conflitto come messaggio a un altro processo di risoluzione dei conflitti. Dropbox lo risolve creando un nuovo file e nominandolo "PrevFileName Copia in conflitto del nome utente (yyyy-MM-dd) .ext". Forse questo potrebbe essere modificato attraverso un piccolo widget, se si sta compilando contro quella singola fonte: il widget potrebbe rilevare le modifiche in sospeso come messaggi / eventi e scegliere il protocollo di risoluzione dei conflitti. Pertanto, quando si programma su una cartella in modalità esclusiva, la VM di Windows potrebbe impostare il widget su "esclusivo".
Questo avrebbe questi PRO
- Sarebbe non bloccante / asincrono
- Sarebbe un'ipotesi ma non richiederebbe che un computer scriva principalmente nei file.
- Funzionerebbe con file di dimensioni arbitrarie
- Funzionerebbe su * nix e Windows legando insieme i progetti menzionati.
- Funzionerebbe quando è necessaria un'elevata capacità di lettura (ovvero i file si trovano fisicamente sul disco)
- Quando vengono raggiunti gli eventi in conflitto, è possibile fornire un'app di interfaccia utente che consenta all'utente di scrivere / scaricare plug-in che agiscono in modo sano per diversi tipi di eventi, ad esempio diversi tipi di file. Per esempio. un file di testo potrebbe essere richiamato con Kompare / WinDiff, mentre un file binario verrebbe duplicato e salvato come un altro file.