Synchronize local directories with Tahoe-LAFS storage grids

Gridsync

Gridsync aims to provide a cross-platform, graphical user interface for Tahoe-LAFS, the Least Authority File Store. It is intended to simplify the Tahoe-LAFS installation and configuration process and ultimately provide user-friendly mechanisms for common use-cases like backing up local files, synchronizing directories between devices, and sharing files and folders with other users across all major desktop platforms (GNU/Linux, macOS, and Windows). More broadly, Gridsync aims to duplicate most of the core functionality provided by other, proprietary "cloud" backup and synchronization services and utilities (such as Dropbox and BitTorrent Sync) but without demanding any sacrifice of the user's privacy or freedom -- and without requiring usage or knowledge of the command line. Accordingly, Gridsync is developed with the goal in mind of making secure cloud storage freely available to everyone, without exception, without added barriers, and regardless of one's operating system choice.

Why Gridsync?

Tahoe-LAFS already provides a number of highly desirable properties for secure file-storage: in addition to offering client-side encryption, it is decentralized, robust, free (as in both beer and speech), stable and mature, and written by a group of very talented developers. Unfortunately -- and despite all of its technical merits -- Tahoe-LAFS has a number of persistent usability issues which steepen its learning curve: its installation requires manual compilation from source on Windows and macOS, its configuration consists in hand-editing text files, its primary interface requires heavy command line usage, and many of its fundamental concepts (e.g., "dircap", "shares", "servers-of-happiness") are opaque to new users or otherwise demand additional reading of the project's extensive documentation. Accordingly, Tahoe-LAFS' userbase consists primarily in seasoned developers and system administrators; non-technical users are naturally excluded from enjoying Tahoe-LAFS's aforementioned advantages.

The Gridsync project intends to overcome some of Tahoe-LAFS's usability barriers by means of following features:

  • "Batteries included" packaging -- Gridsync bundles will include Tahoe-LAFS and all required dependencies for a frictionless installation experience; no python installation or manual compilation is required.
  • A graphical user interface for managing primary Tahoe-LAFS functionality (e.g., starting, stopping, configuring gateways) -- the user will never have to edit a text file by hand or touch the command line.
  • "Native" look and feel -- Gridsync uses the Qt application framework, emulating native widgets on all target platforms; the user can expect Gridsync to behave like any other desktop application.
  • Automated bi-directional file synchronization -- Gridsync will monitor local and remote directories, seamlessly storing or retrieving new versions of files as they appear (using Tahoe-LAFS' "Magic Folder" feature [*] ).
  • Status indicators -- the user will know, at a glance, the number of connected storage nodes, folder sizes and modification times, when folders are synchronizing, recently updated files, etc.
  • Desktop integration -- Gridsync can (optionally) start automatically on login and provide desktop notifications when certain operations have completed.
  • Easy sharing -- Gridsync uses the magic-wormhole library to provide human-pronounceable "invite codes" for joining storage grids and sharing folders with other users.
  • Simple recovery -- Gridsync's "Recovery Key" subsystem allows connections and folders to be easily restored from a single file in the event of a disaster.
  • Tor support (experimental) -- Gridsync can tunnel outgoing connections through the Tor anonymity network, concealing users' network location from storage service providers and each other.
[*] Tahoe-LAFS' "Magic Folder" functionality is not (yet) fully supported on macOS or other BSD-based operating systems and is presently marked as experimental.

Screenshots (latest release; running macOS 10.14 with dark mode enabled):

https://raw.githubusercontent.com/gridsync/gridsync/master/images/screenshots/latest/02-drag-and-drop.png

https://raw.githubusercontent.com/gridsync/gridsync/master/images/screenshots/latest/03-syncing.png

https://raw.githubusercontent.com/gridsync/gridsync/master/images/screenshots/latest/04-history.png

https://raw.githubusercontent.com/gridsync/gridsync/master/images/screenshots/latest/05-invite.png

Screenshots (previous releases; running GNU/Linux with Xfce 4):

https://raw.githubusercontent.com/gridsync/gridsync/master/images/screenshots/old/welcome.png

https://raw.githubusercontent.com/gridsync/gridsync/master/images/screenshots/old/connecting.png

https://raw.githubusercontent.com/gridsync/gridsync/master/images/screenshots/old/dropzone.png

https://raw.githubusercontent.com/gridsync/gridsync/master/images/screenshots/old/passphrase.gif

https://raw.githubusercontent.com/gridsync/gridsync/master/images/screenshots/old/menu.png

https://raw.githubusercontent.com/gridsync/gridsync/master/images/screenshots/old/share.png

https://raw.githubusercontent.com/gridsync/gridsync/master/images/screenshots/old/notify.gif

https://raw.githubusercontent.com/gridsync/gridsync/master/images/screenshots/old/history.png

Installation and running:

Stable releases:

Downloads for "stable" releases of Gridsync can be found on the project's GitHub Releases page and include pre-built/binary distrubitions for all three major desktop platforms that have been compiled inside dedicated virtual machines on dedicated hardware. Users wishing to install these packages are strongly urged to verify their signatures before running or, alternatively, to build/install Gridsync manually from source (see below).

To install and run Gridsync on GNU/Linux (64-bit only; supporting glibc 2.17 and above -- including Debian 9+, Ubuntu 16.04 LTS+, CentOS 7+, and Fedora 28+):

  1. Download Gridsync-Linux.AppImage (and verify its signature)
  2. Make the AppImage executable (chmod +x Gridsync-Linux.AppImage)
  3. Run Gridsync-Linux.AppImage

To install and run Gridsync on macOS (64-bit only; supporting macOS 10.13 "High Sierra" and above):

  1. Download Gridsync-macOS.dmg (and verify its signature)
  2. Drag the enclosed "Gridsync.app" bundle anywhere (e.g., ~/Applications)
  3. Double-click Gridsync.app

To install and run Gridsync on Windows (64-bit only; supporting Windows Server 2012R2, Windows 7 SP1, Windows 8.1, and Windows 10):

  1. Download Gridsync-Windows-setup.exe (and verify its signature)
  2. Run the executable installer and follow/complete the setup wizard
  3. Select "Launch Gridsync" when installation is finished

Alternatively, Windows users who do not wish to use the executable installer can download and verify Gridsync-Windows.zip, extract the enclosed "Gridsync" folder anywhere, and run Gridsync.exe.

From source:

Because Tahoe-LAFS has not yet been ported to python3, and because some GNU/Linux distributions might contain especially old versions of some dependencies, it is recommended to install and run Tahoe-LAFS and Gridsync inside their own virtual environments using updated dependencies from PyPI (ideally with hashes verified).

The following series of steps (run from the top level of the Gridsync source tree) should work on most Debian-based GNU/Linux distributions:

sudo apt-get install build-essential libffi-dev libssl-dev python python-dev python3 python3-dev virtualenv
virtualenv --python=python2 ./venv2
./venv2/bin/python -m pip install --upgrade setuptools pip
./venv2/bin/python -m pip install tahoe-lafs
virtualenv --python=python3 ./venv3
./venv3/bin/python -m pip install --upgrade setuptools pip
./venv3/bin/python -m pip install -r requirements/requirements-hashes.txt
./venv3/bin/python -m pip install .
PATH=$PATH:./venv2/bin ./venv3/bin/gridsync

Users of other distributions and operating systems should modify the above steps as required (for example, by installing Xcode on macOS in addition to python -- or the dependencies listed at the top of make.bat in the case of Windows).

Alternatively, users can use PyInstaller to generate a more "portable" binary distribution of Gridsync and Tahoe-LAFS (suitable for running on other machines of the same platform) by installing the required dependencies and typing make in the top-level of the source tree. This will create a standalone executable distribution of Gridsync and all of its dependencies (including a "frozen" python interpreter and Tahoe-LAFS), placing the resultant files/installers in the dist/ subdirectory.

Note, however, that PyInstaller-generated binaries are typically not backward-compatible; a PyInstaller executable that was built on a newer GNU/Linux distribution, for example (i.e., with a more recent version of glibc) will not run on older distributions. Accordingly, if you intend to distribute Gridsync binaries for use on a wide range operating system versions, it is recommended that you build the application on as old of a system as is reasonable for a given platform (i.e., one which can build and run Gridsync but which still receives security updates). Presently, CentOS 7, macOS "Mojave" (10.14), and Windows Server 2012 R2 arguably constitute the most suitable candidates for GNU/Linux, macOS, and Windows build systems respectively (insofar as binaries generated on these systems will be forward-compatible with all others in that platform-category that are still supported upstream).

To help facilitate the testing, building, and distribution of forward-compatible binaries -- as well as to enable a crude form of "cross-compilation" -- a custom Vagrantfile has been provided inside the Gridsync source tree; users or developers with Vagrant and VirtualBox installed [†] can automatically provision a complete Gridsync build environment that produces forward-compatible binaries via the following commands:

make vagrant-build-linux
make vagrant-build-macos
make vagrant-build-windows

These will download and configure a suitable virtual machine for the target platform (from the public Vagrant Boxes catalog), provision it with all required dependencies (such compilers/SDKs, python interpreters, X11 libraries, etc.), copy the Gridsync source code into the target VM, run the Gridsync test suite, and compile a final PyInstaller-generated binary package suitable for distribution (the result of which can be found in the ~/gridsync/dist directory of the guest VM).

[†] Note that in order to get Vagrant/VirtualBox working properly, users of GNU/Linux may need to add the current user's name to the local "vboxusers" group, while users experiencing issues with Windows guests may need to install some combination of the winrm, winrm-fs, or winrm-elevated Vagrant plugins (via the vagrant plugin install winrm winrm-fs winrm-elevated command). For further assistance with installing, configuring, or using Vagrant and/or VirtualBox on your system, please consult the appropriate upstream documentation and/or help forums. In addition, please note that Gridsync project can make no guarantees about the security or safety of public Vagrant "Boxes"; please exercise appropriate caution when relying upon third-party software.

Alternatively, users with docker installed can use the CentOS 7-based gridsync-builder image to build equivalent backward-compatible binaries without the addded overhead of Vagrant and VirtualBox:

make in-container

Development builds:

Unsigned binary distributions (currently tracking the master branch) are also available from the project buildbot's "artifacts" directory. These packages, however, should not be considered trustworthy or reliable in any way and are made available only for testing purposes by developers. Please excercise appropriate caution when using these files (ideally by downloading and running them inside a disposable virtual machine).

Known issues and limitations:

While Gridsync ultimately aims to provide an easy-to-use frontend for users of Tahoe-LAFS, at present, its interface only supports a very limited subset of Tahoe-LAFS's underlying features and potential use-cases (namely, it provides simplified means for joining storage grids, creating and sharing "magic-folders," and receiving status updates and notifications pertaining to those processes). Accordingly, users should not (yet) expect Gridsync to provide a complete backup solution or to serve as a stand-in replacement for other tools with robust sharing and collaboration capabilities.

In addition, it should be noted that Tahoe-LAFS's "magic-folder" functionality itself is currently considered "experimental" and has a number of known issues and limitations and open development tickets.

Contributing:

Contributions of any sort (e.g., suggestions, criticisms, bug reports, pull requests) are welcome. Any persons interested in aiding the development of Gridsync are encouraged to do so by opening a GitHub Issue or by contacting its primary developer: [email protected]

License:

Copyright (C) 2015-2021 Christopher R. Wood

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>.

Sponsors:

The ongoing development of this project has been made possible by the generous sponsorships and grants provided by Least Authority (2016-), Internews/UXFund (2017), and Open Technology Fund (2019-2020).

Comments
  • PyQt5 5.13.2 breaks macOS window textures/content if dark mode is enabled

    PyQt5 5.13.2 breaks macOS window textures/content if dark mode is enabled

    PyQt 5.13.2 breaks window textures and content in Gridsync, causing windows to appear blank or transparent. The following error messages were observed (which may point to two separate issues):

    2019-11-22 17:20:58.416 Gridsync[24524:2438424] *** WARNING: Textured window <QNSPanel: 0x7faf33598830; contentView=NSObject(0x0)> is getting an implicitly transparent titlebar. This will break when linking against newer SDKs. Use NSWindow's -titlebarAppearsTransparent=YES instead.
    2019-11-22 17:20:58.471 Gridsync[24524:2438424] It does not make sense to draw an image when [NSGraphicsContext currentContext] is nil.  This is a programming error. Break on void _NSWarnForDrawingImageWithNoCurrentContext(void) to debug.  This will be logged only once.  This may break in the future.
    

    I could not reproduce the issue on macOS Sierra (10.12) or High Sierra (10.13) but, on Mojave, downgrading/pinning PyQt5 to version 5.13.1 seemingly corrects the issue, resulting in window textures rendering correctly. As a result, Gridsync builds should temporarily(?) downgrade/pin the PyQt5 package until the code paths that cause the above two errors can be identified and fixed.

  • Consume Eliot logs from Tahoe-LAFS

    Consume Eliot logs from Tahoe-LAFS

    Tahoe-LAFS recently gained some amount of structured logging using the Eliot logging library. Such logs are not written anywhere by default but can be written to a file with a command line argument. Development is currently in progress to expose these logs via a WebSocket-based interface served the the Tahoe-LAFS node, allowing the logs to be consumed without ever committing them to disk.

    GridSync could consume this WebSocket API to receive these Eliot log events from the Tahoe-LAFS node. This would be useful if information is being collected to diagnose a Tahoe-LAFS misbehavior (either by the user or to create a report to send upstream).

  • Add Nix-based development shell and related CI

    Add Nix-based development shell and related CI

    This makes nix develop work with a recent-enough version of Nix (with flakes enabled). The resulting environment contains enough stuff for tox -e py39,integration,lint to succeed.

    Also included is a new GitHub Actions job to do these things on CI, mostly to ensure they keep working (and so remain useful for development work on GridSync on NixOS or with Nix tools on other OS).

  • AppImage crashes with error: undefined symbol: pango_coverage_get_type

    AppImage crashes with error: undefined symbol: pango_coverage_get_type

    Hello, I'm trying out gridsync with the public test grid, and getting some crashes before I can begin uploading any files. I'm running the latest (0.5.0) AppImage on Arch Linux.

    Here are the logs, obtained just by running ./Gridsync-Linux.AppImage in the terminal:

    /usr/lib/gvfs/libgvfscommon.so: undefined symbol: g_task_set_name
    Failed to load module: /usr/lib64/gio/modules/libgvfsdbus.so
    libpng warning: iCCP: profile 'icc': 0h: PCS illuminant is not D50
    libpng warning: iCCP: profile 'icc': 0h: PCS illuminant is not D50
    Fontconfig warning: "/usr/share/fontconfig/conf.avail/05-reset-dirs-sample.conf", line 6: unknown element "reset-dirs"
    libpng warning: iCCP: profile 'icc': 0h: PCS illuminant is not D50
    libpng warning: iCCP: profile 'icc': 0h: PCS illuminant is not D50
    libpng warning: iCCP: profile 'icc': 0h: PCS illuminant is not D50
    libpng warning: iCCP: profile 'icc': 0h: PCS illuminant is not D50
    libpng warning: iCCP: profile 'icc': 0h: PCS illuminant is not D50
    libpng warning: iCCP: profile 'icc': 0h: PCS illuminant is not D50
    qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 1345, resource id: 13028294, major code: 40 (TranslateCoords), minor code: 0
    /usr/lib/gvfs/libgvfscommon.so: undefined symbol: g_task_set_name
    Failed to load module: /usr/lib64/gio/modules/libgioremote-volume-monitor.so
    /usr/lib/gvfs/libgvfscommon.so: undefined symbol: g_task_set_name
    Failed to load module: /usr/lib64/gio/modules/libgvfsdbus.so
    /usr/lib/gvfs/libgvfscommon.so: undefined symbol: g_task_set_name
    Failed to load module: /usr/lib64/gio/modules/libgioremote-volume-monitor.so
    
    (gridsync:28223): Gtk-WARNING **: 13:28:04.046: Could not load a pixbuf from icon theme.
    This may indicate that pixbuf loaders or the mime database could not be found.
    **
    Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/share/icons/breeze-dark/status/16/image-missing.svg: Unable to load image-loading module: /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: /usr/lib/librsvg-2.so.2: undefined symbol: pango_coverage_get_type (gdk-pixbuf-error-quark, 5)
    [1]    28215 IOT instruction (core dumped)  ./Gridsync-Linux.AppImage
    

    I assume it's only that last log line that is relevant to the crash:

    Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/share/icons/breeze-dark/status/16/image-missing.svg: Unable to load image-loading module: /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: /usr/lib/librsvg-2.so.2: undefined symbol: pango_coverage_get_type (gdk-pixbuf-error-quark, 5)
    

    To me this seems like some sort of software library versioning issue. I'm running fully updated Arch Linux, which has very recent software. Maybe the AppImage is trying to use some system library that is newer that it is expecting, causing the missing symbol? I would've thought AppImage packaging would bundle all these libraries, but maybe that's not how it works.

    My gdk-pixbuf version is 2.42.8, if that helps. Let me know if there's any other info I can provide.

  • Exit handling subprocess pidfiles

    Exit handling subprocess pidfiles

    There is an appropriate magic-folder release (22.10.0) but not yet for Tahoe-LAFS (using https://github.com/tahoe-lafs/tahoe-lafs/pull/1221 would work).

  • Tor proxy bypass

    Tor proxy bypass

    Using gridsync 0.4.1 with a paid s4 account on GNU/Linux (BuildID[sha1]=28ba79c778f7402713aec6af319ee0fbaf3a8014). Tor is enabled and there are direct connections from the gridsync application to Amazon ec2 to the host ec2-52-6-180-137.compute-1.amazonaws.com.. The host name wormhole.leastauthority.com resolves to 52.6.180.137 and resources/config.txt defines relay = ws://wormhole.tahoe-lafs.org:4000/v1 as the wormhole server. This IP and port match the Tor proxy bypass on my system:

    gridsync  18326 user   72u  IPv4 698349      0t0  TCP 10.0.0.6:50130->52.6.180.137:4000 (ESTABLISHED)
    gridsync  18326 user   79u  IPv4 700071      0t0  TCP 10.0.0.6:50132->52.6.180.137:4000 (ESTABLISHED)
    gridsync  18326 user   81u  IPv4 699385      0t0  TCP 10.0.0.6:50108->52.6.180.137:4000 (ESTABLISHED)
    

    I understand that Tor support is experimental and wanted to warn others that the rendezvous process, as well as Gridsync, does not appear to be protected by Tor at this time. This is persistent even when magic-wormhole isn't in active use. It appears after the use of magic-wormhole and it persists until restarting gridsync.

  • Change to appid used by Tahoe-LAFS invite feature

    Change to appid used by Tahoe-LAFS invite feature

    Fixes #49

    I wasn't sure if it made more sense to make this PR against master or dev. Let me know if you want me to re-do it against dev. Or to do a follow-up duplicating it against dev?

  • Put a Python environment containing magic-folder into GridSync's runtime env

    Put a Python environment containing magic-folder into GridSync's runtime env

    This gives the Nix-packaged GridSync a magic-folder to use.

    This won't work until https://github.com/LeastAuthority/magic-folder/pull/527 and the nixpkgs version used in GridSync's Nix packaging is bumped to include a magic-folder with that change.

    Note that in one commit message I wrote "virtualenv" but of course this uses a Nix Python environment, not a virtualenv. They are vaguely similar in outcome but one is not based on the other and the internals are not even particularly similar.

  • Upgrade to Qt 5.13

    Upgrade to Qt 5.13

    (Py)Qt 5.13 was recently released and contains some improvements pertaining to Wayland support that will probably be beneficial to users of newer Linux distros and desktop environments that make use of it. Gridsync should upgrade from Qt 5.12 -- so long as doing so doesn't cause any regressions.

    EDIT: It looks like I misread; while Qt 5.13 is indeed now available, the PyQt bindings have not yet been updated for 5.13 (they did, however, just put out a 5.12.3 release). I'll leave this open, nonetheless, as a reminder to upgrade once the PyQt bindings become available...

  • Size overflow?

    Size overflow?

    I'm using v0.3.1. I've started Gridsync (in debug mode) and after a while size has become negative:

    screenshot_2018-04-09_06-09-43

    Unfortunately, when that happened, there has been nothing out of the ordinary in the logs (only another add_updated_file entry), but I can send GPG-encrypted logs on demand.

  • `python-challenge-bypass-ristretto` has dropped support for macOS 10.14

    `python-challenge-bypass-ristretto` has dropped support for macOS 10.14

    The latest PyPI release of the python-challenge-bypass-ristretto library has dropped support for macOS 10.14. The Gridsync project, however, currently maintains and depends on a macOS 10.14 buildbot-worker in order to maintain forward-compatibility for PyInstaller builds.

    Accordingly, the Gridsync project should either update the macOS 10.14 buildbot-worker/CI configuration to (reproducibly) build the rust-based python-challenge-bypass-ristretto library or explicitly drop support for macOS 10.14 (i.e., update builders to target macOS 10.15 and higher) -- preferably the latter...

  • Python 3.11

    Python 3.11

    Python 3.11 has recently been released, bringing numerous performance-related improvements (among other things).

    Gridsync should add support for Python 3.11 and default to using/shipping a Python 3.11 interpreter once it is supported by our dependencies and any/all regressions are resolved, etc.

  • GridSync crashes when clicking

    GridSync crashes when clicking "Add New..." and not yet connected or invited.

    I'm using NixOS and Python 3.10 and ran nix develop , then python -m tox to run the tests and build the program.

    I then run the program with ./tox/py310/bin/gridsync

    I don't have an invite code, so I clicked "Add new..." in the ComboBox at the top ( https://github.com/gridsync/gridsync/blob/main/gridsync/gui/toolbar.py#L39 ? ) and the application crashes with

    Traceback (most recent call last):
      File "/home/shae/build/gridsync/gridsync/gui/toolbar.py", line 49, in on_activated
        logging.debug("Selected %s", gateway.name)
    AttributeError: 'NoneType' object has no attribute 'name'
    Aborted (core dumped)
    
  • HTML-ized Tahoe-LAFS WAPI errors are unwieldy

    HTML-ized Tahoe-LAFS WAPI errors are unwieldy

    By default, the Tahoe-LAFS web API wraps response bodies for HTTP 500 errors in HTML/CSS, making it more difficult for applications like Gridsync to parse and/or display such content to humans in text form. As it turns out, there's a way to disable this behavior and have such stack traces returned in plain text. From the Tahoe-LAFS WAPI docs:

    Unusual exceptions may result in a 500 Internal Server Error as a catch-all, with a default response body containing a Nevow-generated HTML-ized representation of the Python exception stack trace that caused the problem. CLI programs which want to copy the response body to stderr should provide an “Accept: text/plain” header to their requests to get a plain text stack trace instead.

    Gridsync's interactions with the Tahoe-LAFS web API should include this header where possible in order to facilitating the handling of such errors.

    See also https://github.com/LeastAuthority/magic-folder/issues/679

  • The (PGP) release signing key has expired

    The (PGP) release signing key has expired

    The Gridsync release signing key has recently expired.

    Although PGP expiry dates are somewhat arbitrary or policy-driven and do not strictly restrict the continued usage of a given key, it would be a good idea to issue a new signing keypair. Given the multitude of problems with PGP, however, it may be an even better idea to explore other non-PGP alternatives for future release-signing...

  • Draft: GUI tests using pytest-qt (WIP)

    Draft: GUI tests using pytest-qt (WIP)

    In this WIP PR I try to provide some good first "click & press buttons" (in contrast to lower level stuff like sending signals) GUI tests using pytest-qt.

    Note to self: Run a single test by issuing a command line like: py -m tox -epy310 -- tests/gui/test_charter.py::test_recover_from_key

    @elric-wamugu please have a look & try this out on your machine - maybe you would like to work on this together for a session or two?

Related tags
Nerd-Storage is a simple web server for sharing files on the local network.
Nerd-Storage is a simple web server for sharing files on the local network.

Nerd-Storage is a simple web server for sharing files on the local network. It supports the download of files and directories, the upload of multiple files at once, making a directory, updates and deletions.

Jun 7, 2022
The command-line tool that gives easy access to all of the capabilities of B2 Cloud Storage

B2 Command Line Tool The command-line tool that gives easy access to all of the capabilities of B2 Cloud Storage. This program provides command-line a

Dec 4, 2022
a full featured file system for online data storage

S3QL S3QL is a file system that stores all its data online using storage services like Google Storage, Amazon S3, or OpenStack. S3QL effectively provi

Dec 2, 2022
The Tahoe-LAFS decentralized secure filesystem.
The Tahoe-LAFS decentralized secure filesystem.

Free and Open decentralized data store Tahoe-LAFS (Tahoe Least-Authority File Store) is the first free software / open-source storage technology that

Dec 3, 2022
Fully Automated YouTube Channel ▶️with Added Extra Features.

Fully Automated Youtube Channel ▒█▀▀█ █▀▀█ ▀▀█▀▀ ▀▀█▀▀ █░░█ █▀▀▄ █▀▀ █▀▀█ ▒█▀▀▄ █░░█ ░░█░░ ░▒█░░ █░░█ █▀▀▄ █▀▀ █▄▄▀ ▒█▄▄█ ▀▀▀▀ ░░▀░░ ░▒█░░ ░▀▀▀ ▀▀▀░

Dec 1, 2022
A bot discord that can create directories, file, rename, move, navigate throw directories etc....
A bot discord that can create directories, file, rename, move, navigate throw directories etc....

File Manager Discord What is the purpose of this program ? This program is made for a Discord bot. Its purpose is to organize the messages sent in a c

Feb 2, 2022
Sink is a CLI tool that allows users to synchronize their local folders to their Google Drives. It is similar to the Git CLI and allows fast and reliable syncs with the drive.
Sink is a CLI tool that allows users to synchronize their local folders to their Google Drives. It is similar to the Git CLI and allows fast and reliable syncs with the drive.

Sink is a CLI synchronisation tool that enables a user to synchronise local system files and folders with their Google Drives. It follows a git C

May 29, 2022
Synchronize a local directory of songs' (MP3, MP4) metadata (genre, ratings) and playlists with a Plex server.

PlexMusicSync Synchronize a local directory of songs' (MP3, MP4) metadata (genre, ratings) and playlists (m3u, m3u8) with a Plex server. The song file

Jul 7, 2022
Ralph is a command-line tool to fetch, extract, convert and push your tracking logs from various storage backends to your LRS or any other compatible storage or database backend.

Ralph is a command-line tool to fetch, extract, convert and push your tracking logs (aka learning events) from various storage backends to your

Nov 9, 2022
DNA Storage Simulator that analyzes and simulates DNA storage

DNA Storage Simulator This monorepository contains code for a research project by Mayank Keoliya and supervised by Djordje Jevdjic, that analyzes and

Sep 25, 2022
Qtas(Quite a Storage)is an experimental distributed storage system developed by Q-team in BJFU Advanced Computer Network sources.

Qtas(Quite a Storage)is a experimental distributed storage system developed by Q-team in BJFU Advanced Computer Network sources.

Jan 12, 2022
Qtas(Quite a Storage)is an experimental distributed storage system developed by Q-team in BJFU Advanced Computer Network sources.

Qtas(Quite a Storage)is a experimental distributed storage system developed by Q-team in BJFU Advanced Computer Network sources.

Jan 12, 2022
Storage-optimizer - Identify potintial optimizations on the cloud storage accounts

Storage Optimizer Identify potintial optimizations on the cloud storage accounts

Feb 13, 2022
Construct and use map tile grids in different projection.

Morecantile +-------------+-------------+ ymax | | | | x: 0 | x: 1 | | y: 0 | y: 0

Nov 26, 2022
A Python framework for developing parallelized Computational Fluid Dynamics software to solve the hyperbolic 2D Euler equations on distributed, multi-block structured grids.
A Python framework for developing parallelized Computational Fluid Dynamics software to solve the hyperbolic 2D Euler equations on distributed, multi-block structured grids.

pyHype: Computational Fluid Dynamics in Python pyHype is a Python framework for developing parallelized Computational Fluid Dynamics software to solve

Nov 22, 2022
A small script to migrate or synchronize users & groups from Okta to AWS SSO
A small script to migrate or synchronize users & groups from Okta to AWS SSO

aws-sso-sync-okta A small script to migrate or synchronize users & groups from Okta to AWS SSO Changelog Version Remove hardcoded values on variables

Feb 11, 2022
Subtitle Workshop (subshop): tools to download and synchronize subtitles

SUBSHOP Tools to download, remove ads, and synchronize subtitles. SUBSHOP Purpose Limitations Required Web Credentials Installation, Configuration, an

Feb 13, 2022
Synchronize Two Cameras in Real Time using Multiprocessing
Synchronize Two Cameras in Real Time using Multiprocessing

Synchronize Two Cameras in Real Time using Multiprocessing In progress ... ?? Project Structure ?? Install Libraries for this Project (requirements.tx

Oct 31, 2021
Nerd-Storage is a simple web server for sharing files on the local network.
Nerd-Storage is a simple web server for sharing files on the local network.

Nerd-Storage is a simple web server for sharing files on the local network. It supports the download of files and directories, the upload of multiple files at once, making a directory, updates and deletions.

Jun 7, 2022
A simple MTProto-based bot that can download various types of media (>10MB) on a local storage

TG Media Downloader Bot ?? A telegram bot based on Pyrogram that downloads on a local storage the following media files: animation, audio, document, p

Nov 1, 2022