git-remote-dropbox VS s3fs-fuse

For what it's worth, git also can fail in some pretty bizarre ways in Dropbox for much the same reasons. I've used git-remote-dropbox [1] in the past to use Dropbox as a git server.

[1] https://github.com/anishathalye/git-remote-dropbox

If you want to use dropbox, then you should use the dropbox/git bridge, which lets git speak to dropbox somewhat directly, bypassing these problems.

This is a high-level overview. No summary of API requests, but all the file I/O is in helper.py, so you can look there. At a high level, we rely on atomic (over)write and atomic test-and-set. Different primitives could work too, as long as there's some way to get concurrency control through the API.

So, if you really want to use dropbox for syncing git repos, this plugin solves the problem well:

https://github.com/anishathalye/git-remote-dropbox

For me, it solved all of the corruption problems with using Dropbox for git storage. In the end, I decided it was too heavy weight, and wanted to be able to clone my repo on machines that might not have anything other than "git" installed, but until I reached that point, I was a happy user of it.

I'm not aware of a similar tool for syncthing.

Yeah there are tools that help in doing that. e.g, git-remote+dropbox

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/

sudo apt install build-essential libfuse-dev fuse git clone https://github.com/s3fs-fuse/s3fs-fuse.git cd s3fs-fuse sudo apt install libfuse2 sudo apt install libcurl4-openssl-dev sudo apt install libxml2-dev ./autogen.sh ./configure make

Don’t know actually. Here is project page.

s3fs-fuse

How is this different than these other solutions?

https://github.com/kahing/goofys

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

I don’t get it. Why not just improve https://github.com/s3fs-fuse/s3fs-fuse