ksync - an okay file synchronisation solution, written in Rust

Overview

ksync - an okay file synchronisation solution

ksync is a simple, immutable, file synchronisation solution written in Rust, using the tokio async framework, and the sled database. It aims to be a simple to use, easy to configure solution for syncing your files between devices.

⚠️ WARNING ⚠️

ksync is alpha software, and it should not be relied on in-production or to safely manage any critical information. If you do use ksync in this way, please make sure to manually create backups of your data just in-case of failure.

Additionally, ksync currently does not provide any sort of authentication, nor are it's communications encrypted, so do not expose a ksync server to the internet.

Motivation

Most file synchronisation solutions that I found while looking for a way to sync my password database between my devices seem to be used to keep 2 folders, on the client and the server, in sync.

While this is perfectly fine (and honestly would have worked for my purposes), this means that these solutions are limited by the host filesystem, namely:

  1. rollbacks require either using snapshots (e.g. via btrfs), or manually archiving the sync folder.
  2. compression and file de-duplication are reliant on the host filesystem to work, otherwise are non-existent.

ksync solves (in an incomplete fashion, see; #1) the first problem through it's immutable design; whenever the filesystem tree is updated, it creates a new tree, and old trees will be able to be accessed simply by going back through a list of instances of the filesystem.

The second problem is already solved by ksync. While compression is not yet enabled, sled does support it, so it should simply be a case of enabling it in the codebase (will be done when the need arises). File de-duplication is already solved, as "objects" (pieces of data stored on the server), are indexed via a hash of their contents. This means that 2 files that have the same contents will occupy the same object.

Building & Running

In order to build ksync, you will need to have Rust installed, with the nightly toolchain. You can get rust from rustup.

Building

cargo build

Running

# RUST_LOG=info gives us more useful output. only useful for daemon mode
RUST_LOG=info cargo run -- <ARGS>

Usage

The basic usage of ksync is as follows:

# start a ksync daemon with a given configuration
ksync daemon -c [CONFIG FILE]
# interact with a ksync server with the command line interface
ksync cli [IP ADDRESS] [METHOD] [ARGS...]

Note: You can run ksync -h to see basic usage information. You can also ask for help for a given subcommand in the same way, e.g. ksync cli 127.0.0.1:8080 get -h.

Command-line interface

Currently, ksync exposes only a few commands.

insert, get, and delete

You can insert and retrieve files from the ksync database via the insert and get subcommands respectively.

# insert a file into the database
ksync cli 127.0.0.1:8080 insert --from example/test.txt --to /files/test.txt
# retrieve a file from the database
ksync cli 127.0.0.1:8080 get --from /files/test.txt --to example/test.txt

You cal also use -f and -t in place of --from and --to.

You can also delete files via the delete command

ksync cli 127.0.0.1:8080 delete --path /files/test.txt
ksync cli 127.0.0.1:8080 delete -p /files/test.txt

get-listing and get-node

At the moment, the get-listing and get-node subcommands function virtually identically, returning a listing of files on the server, however get-node takes in an argument -p for you to specify the path to get a listing from. This is part of a broader move to make more operations relative to a given path or revision of the filesystem.

# get a list of files from the database in the format of `:  @ `
ksync cli 127.0.0.1:8080 get-listing 
# clear the database of a given server
ksync cli 127.0.0.1:8080 clear

clear and rollback

The clear command is used to clear the ksync database, reverting it back to an empty file server with only the root (/) node. You can `rollback``:

  • by a number relative to the latest version of the filesystem
  • by a number relative to the earliest version of the filesystem
  • to a given time Keep in mind that the time is the number of nanoseconds since the UNIX epoch. There will be date/time parsing for this purpose later on.
# clear the database
ksync cli 127.0.0.1:8080 clear

# rollback to the earliest revision of the filesystem
ksync cli 127.0.0.1:8080 rollback earliest 0
# rollback the last 3 version of the filesystem
ksync cli 127.0.0.1:8080 rollback latest 3
# rollback to a given time (UNIX timestamp in nanoseconds)
ksync cli 127.0.0.1:8080 rollback time 1234567891011121314

Configuration

The configuration for ksync is very simple (both by design, and because it is so early in it's development).

Note: while there are 2 example configuration files, you can have a single ksync instance act as both a server and a synchronisation client; this could be useful if you want, for example, to use a directory on the same machine as an interface to the database; this will duplicate the information found inside the server's database into that folder, and will synchronise the two.

Server

See example/server.toml for the example configuration. Server configuration is specified inside of the [server] block.

  • addr - the socket address the server will bind to, e.g.g 127.0.0.1:8080.
  • db - path to the server's files database.

Sync Client

See example/client.toml for the example configuration. Synchronisation client configuration is specified inside of the [sync] block.

  • remote - the socket address of a ksync server to connect to/sync with.
  • resync_time - the time (in seconds) between automatically re-syncing with the server
  • point - the point to synchronise data to/from
    • dir - the directory to synchronise

License

ksync is licensed under the GNU General Public License, version 3 or later; please see LICENSE for more details

You might also like...
A cross-platform terminal database tool written in Rust
A cross-platform terminal database tool written in Rust

gobang is currently in alpha A cross-platform terminal database tool written in Rust Features Cross-platform support (macOS, Windows, Linux) Mu

FeOphant - A SQL database server written in Rust and inspired by PostreSQL.

A PostgreSQL inspired SQL database written in Rust.

GlueSQL is a SQL database library written in Rust

GlueSQL is a SQL database library written in Rust. It provides a parser (sqlparser-rs), execution layer, and optional storage (sled) packaged into a single library.

Owlyshield is an open-source AI-driven behaviour based antiransomware engine written in Rust.
Owlyshield is an open-source AI-driven behaviour based antiransomware engine written in Rust.

Owlyshield (mailto:[email protected]) We at SitinCloud strongly believe that cybersecurity products should always be open-source: Critical decis

Manage Redshift/Postgres privileges in GitOps style written in Rust

grant-rs An open-source project that aims to manage Postgres/Redshift database roles and privileges in GitOps style, written in Rust. Home | Documenta

A programmable document database inspired by CouchDB written in Rust

BonsaiDb Formerly known as PliantDb. Not yet released on crates.io as BonsaiDb. BonsaiDb aims to be a Rust-written, ACID-compliant, document-database

Distributed SQL database in Rust, written as a learning project

toyDB Distributed SQL database in Rust, written as a learning project. Most components are built from scratch, including: Raft-based distributed conse

Appendable and iterable key/list storage, backed by S3, written in rust

klstore Appendable and iterable key/list storage, backed by S3. General Overview Per key, a single writer appends to underlying storage, enabling many

A simple embedded key-value store written in rust as a learning project

A simple embedded key-value store written in rust as a learning project

Comments
  • Filesystem versioning, rollback/archive support

    Filesystem versioning, rollback/archive support

    Right now, as of the latest commit (41d9f8bd1d971a2c70dc8ed210bfec86204f1364), we keep track of the history of the filesystem; every modification of the filesystem structure creates a new root node, and appends that to the filesystem's history.

    This means that we should have all the infrastructure in place to implement rollbacks and archiving of the filesystem, however I need to work out the best way to approach this. The issue at hand is that, essentially, synchronisation works roughly as follows:

    if remote hash doesn't match local hash:
        compare timestamps
        if local copy newer than remote copy:
            push to server
        else if local copy older than remote copy:
            fetch from server
    

    This works perfectly well when the filesystem is always on the most up-to-date revision, however where it falls apart is when you rollback to an earlier revision of the filesystem. If we were to naively just set an older node as the new current revision of the filesystem, then clients would see that the file timestamps are now older than what they have stored locally, and thus would push to the server their local changes, which would simply revert the filesystem back to what it was before the rollback.

    I need to determine how to notify clients to the fact that a rollback has occured, and that they should re-base the local sync based on the new rollback (ideally, also performing one last sync from the client -> server to ensure any local changes are not lost in the process).

    Beyond synchronisation, we should have the infrastructure in place to allow for the server to:

    • fetch files from an older revision of the filesystem
    • get a listing of an older revision of the filesystem

    The features planned as part of this issue are:

    • [ ] #2
    • [ ] #3
    • [ ] #4
    • [ ] #5

    Any feedback would be much appreciated.

    enhancement 
    opened by jcbsnclr 1
Owner
Jacob Sinclair
Jacob Sinclair
A pure Rust database implementation using an append-only B-Tree file format.

nebari nebari - noun - the surface roots that flare out from the base of a bonsai tree Warning: This crate is early in development. The format of the

Khonsu Labs 194 Jan 3, 2023
Build SQLite virtual file systems (VFS) by implementing a simple Rust trait.

sqlite-vfs Build SQLite virtual file systems (VFS) by implementing a simple Rust trait. Documentation | Example This library is build for my own use-c

Markus Ast 56 Dec 19, 2022
Tool to automate the visualisation of UML dependencies from a SQL file

Doteur A simple tool to draw your mysql relations from exports. Help us If you use the tool, and like it, don't forget to add a star to the project on

Loïc 89 Nov 9, 2022
Plugin for macro-, mini-quad (quads) to save data in simple local storage using Web Storage API in WASM and local file on a native platforms.

quad-storage This is the crate to save data in persistent local storage in miniquad/macroquad environment. In WASM the data persists even if tab or br

ilya sheprut 9 Jan 4, 2023
Cassandra DB native client written in Rust language. Find 1.x versions on https://github.com/AlexPikalov/cdrs/tree/v.1.x Looking for an async version? - Check WIP https://github.com/AlexPikalov/cdrs-async

CDRS CDRS is looking for maintainers CDRS is Apache Cassandra driver written in pure Rust. ?? Looking for an async version? async-std https://github.c

Alex Pikalov 338 Jan 1, 2023
A highly scalable MySQL Proxy framework written in Rust

mysql-proxy-rs An implementation of a MySQL proxy server built on top of tokio-core. Overview This crate provides a MySQL proxy server that you can ex

AgilData 175 Dec 19, 2022
A user crud written in Rust, designed to connect to a MySQL database with full integration test coverage.

SQLX User CRUD Purpose This application demonstrates the how to implement a common design for CRUDs in, potentially, a system of microservices. The de

null 78 Nov 27, 2022
An API Wrapper for https://paste.myst.rs written in rust

PasteMyst.RS pastemyst-rs is an api wrapper for pastemyst written in Rust. ⚠ This package is under development ⚠ Sample usage To get a paste from past

ANF Studios 14 Nov 28, 2021
AgateDB is an embeddable, persistent and fast key-value (KV) database written in pure Rust

AgateDB is an embeddable, persistent and fast key-value (KV) database written in pure Rust. It is designed as an experimental engine for the TiKV project, and will bring aggressive optimizations for TiKV specifically.

TiKV Project 535 Jan 9, 2023
A programmable document database inspired by CouchDB written in Rust

PliantDB PliantDB aims to be a Rust-written, ACID-compliant, document-database inspired by CouchDB. While it is inspired by CouchDB, this project will

Khonsu Labs 718 Dec 31, 2022