onedriver VS goofys

onedriver is a native Linux filesystem for Microsoft OneDrive: - https://github.com/jstaf/onedriver

Alternatively, I read good things about https://github.com/jstaf/onedriver which can download only the files that I need at times instead of the whole account, but looking at the install methods on debian, there's only information regarding Debain 10 and 11 installs. For example, I can install .deb packagaes here, but again only refers to deb 10/11.

There are OneDriveGUI which uses abraunegg's onedrive client as backend, onedriver which has been around with a GUI for longer, and of course the classic Insync which is paid.

I am a big big fan of the OneDriver client - https://github.com/jstaf/onedriver

* Via the 'onedriver' client - https://github.com/jstaf/onedriver - Native file system that only provides the OneDrive 'on-demand' functionality, open source and free. Supports Personal, Business account types. Currently does not support Shared Folders or SharePoint.

/home/my_usr/.cache/paru/clone/onedriver/.gitignore src pkg *.tar.xz *.tar.gz *.tar.zst *.log /home/my_usr/.cache/paru/clone/onedriver/PKGBUILD # Maintained by Faisal Moledina (faisal at moledina dot me) pkgname=onedriver pkgver=0.13.0 pkgrel=0 pkgdesc="Native Linux filesystem for Microsoft OneDrive" arch=('x86_64') url='https://github.com/jstaf/onedriver' license=('GPL3') depends=('fuse2' 'webkit2gtk') makedepends=('pkgconf' 'go') source=("$pkgname-$pkgver.tar.gz::$url/archive/refs/tags/v$pkgver.tar.gz") sha512sums=('aa831017c4d9612fbdea1e2fab05864f84074e6b80e7613ae739d2954e7b6e975d6a1aaaaba330c0038dae69839dcf6> build() { cd "$pkgname-$pkgver" export CGO_CPPFLAGS="${CPPFLAGS}" export CGO_CFLAGS="${CFLAGS}" export CGO_CXXFLAGS="${CXXFLAGS}" export CGO_LDFLAGS="${LDFLAGS}" go build \ -v \ -trimpath \ -buildmode=pie \ -mod=readonly \ -modcacherw \ -ldflags "-X main.commit=$(git rev-parse HEAD) -linkmode external -extldflags \"${LDFLAGS}\"" \ ./cmd/onedriver export CGO_CFLAGS="-Wno-deprecated-declarations ${CFLAGS}" go build \ -v \ -trimpath \ -buildmode=pie \ -mod=readonly \ -modcacherw \ -ldflags "-X main.commit=$(git rev-parse HEAD) -linkmode external -extldflags \"${LDFLAGS}\"" \ ./cmd/onedriver-launcher } package() { cd "$pkgname-$pkgver" install -Dm 755 $pkgname "$pkgdir"/usr/bin/$pkgname install -Dm 755 $pkgname-launcher "$pkgdir"/usr/bin/$pkgname-launcher install -Dm 644 "resources/[email protected]" "$pkgdir"/usr/lib/systemd/user/[email protected] install -Dm 644 resources/$pkgname.desktop "$pkgdir"/usr/share/applications/$pkgname.desktop install -Dm 644 resources/$pkgname.png "$pkgdir"/usr/share/icons/onedriver/$pkgname.png install -Dm 644 resources/$pkgname.svg "$pkgdir"/usr/share/icons/onedriver/$pkgname.svg install -Dm 644 resources/$pkgname.1 "$pkgdir"/usr/share/man/man1/$pkgname.1 }

When you get to it - there are only 5 reliable ways to access OneDrive on Linux/Unix platforms: * Via the OneDrive Client for Linux - https://github.com/abraunegg/onedrive - this 'syncs' your data, bi-directional operation, open source and free. Supports Personal, Business & SharePoint account types and Shared Folders. A Docker container is also available for all major architectures (x86_64, ARMHF, AARCH64). If you need a GUI for onedrive client management use: https://github.com/bpozdena/OneDriveGUI * Via the 'onedriver' client - https://github.com/jstaf/onedriver - Native file system that only provides the OneDrive 'on-demand' functionality, open source and free. Supports Personal, Business account types. Currently does not support Shared Folders or SharePoint. * Via 'rclone' - https://rclone.org/ - one way sync client, open source and free. Has limitations with SharePoint. * Via non-free clients such as 'insync', 'ExpanDrive' * Via the web browser of your choice

There are OneDrive clients for Linux already, e.g. https://github.com/abraunegg/onedrive or https://github.com/jstaf/onedriver.

Take a look at OneDriver. Its a decent OneDrive client for Linux and works really well! It should pair up nicely with LibreOffice, which is a Microsoft Office alternative that is preinstalled on most Distros. Don’t worry, Google Drive also works (honesty not as good as OneDriver). most distros should allow your to “connect to online accounts,” which should allow you to sign in with your g account.

The author needs to ask themselves: in this cloud technology stack, is there POSIX involved somewhere lower down, where I can't access it? The answer is, of course, "yes". The sort of cloud storage systems described all run on top of POSIX APIs. They provide convenience (cost efficiency is more debatable) compared to the POSIX alternative, but that's because they exist at an entirely different conceptual layer (hence the presence of POSIX anyway, just buried).

Your point about surfacing a POSIX that's actually there but hidden and thus visible to low-level Amazon employees building the S3 service which makes it invisible to S3 end customers is true but isn't the the point of the article. The author is saying there are motivations for a POSIX-like api visible also the end user.

So your explanation of stack looks like 2 layers: POSIX api <-- AWS S3 built on top of that

Author's essay is actually talking about 3 layers: POSIX <-- AWS S3 <-- POSIX

That's why the blog post has the following links to POSIX-on-top-of-S3-objects :

https://github.com/s3fs-fuse/s3fs-fuse

https://github.com/kahing/goofys

https://www.cuno.io/

How is this different than these other solutions?

https://github.com/kahing/goofys

https://github.com/s3fs-fuse/s3fs-fuse

But now I ask.. why not s3fs? Is it the GPL licensing? Or even goofys that also have Apache2 licensing and seems to hit similar goals (non fully POSIX compliant)? Why build your own?

If your 20TB is in S3, use a staging box with goofys (https://github.com/kahing/goofys) to mount the commercial S3 bucket(s) into a folder, then use s3 sync to copy to your bucket(s) in GovCloud.

So, we just need to change the dataloader function a bit to make this work then. Did you try just mounting S3 using https://github.com/kahing/goofys. In this case, we need not even change the dataloader code. Not sure of the performance though.

We're using goofys as the mounting utility. It's a "high-performance, POSIX-ish Amazon S3 file system written in Go" based on FUSE (file system in user space) technology.

will probably experiment with https://github.com/kahing/goofys and https://litestream.io/ to make services more easily moved between the devices :) Also, will continue working on https://synpse.net/ to make the operations easier.