fuse
rclone
fuse | rclone | |
---|---|---|
7 | 963 | |
1,555 | 43,840 | |
0.7% | 1.1% | |
0.0 | 9.8 | |
5 months ago | 8 days ago | |
Go | Go | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
fuse
-
FUSE Filesystem
For this first implementation I used Go. After a reviewing some solutions I decided to use https://github.com/bazil/fuse. It seemed to be the easiest way to prototype.
-
Introducing LiteFS
Often, the SQLite database would fit in RAM, and reads would be served straight from the page cache, with no overhead.
Disclaimer: I wrote the FUSE framework LiteFS uses, https://bazil.org/fuse -- and I also have some pending performance-related work to finish, there...
-
I just upgraded to 13.1-RELEASE
I'd love to upgrade but I rely on mounting my Google Drive via /dev/fuse and rclone. There was a post yesterday saying that is broken in 13.1-RELEASE and linking to a FreeBSD bug which links to a rclone bug which links to a bazil bug which seems to have no traction. Someone mentioned a commandline utility that can interact with gdrive but this seems like a pretty bad replacement. IIUC the FreeBSD devs' theory is that a new async system call path exposed a bug in rclone and the blame is there. Anyway, I'm still on 13.0 for now, unfortunately.
-
Just updated to 13.1-Release, some sort of rclone/fuse issue
This was also reported to rclone where someone pointed out that the problem is with fuse lib on FreeBSD and as such is a FreeBSD fuse lib porting problem.
-
Distributed Systems Shibboleths
> 'failed' state and the process itself leaving the accounting tables.
Once again, that cannot be done until the parent process consumes the exit status. That's what the zombie is there for. Zombies don't take up much space.
> Stuck mounts have a half solution (lazy unmounts) but even _that_ interface really also needs a timeout value after which operations on the target should be assumed to fail rather than return correctly.
These days most NFS etc mounts are "soft mounts", that is operations will eventually time out.
Lazy unmount doesn't really apply here, it makes the mountpoint disappear from the global namespace, but all existing open files remain untouched, and the mount lives as long as anything is still using it; it just removes the "entry point" to the mount.
On today's Linux, it's up to each filesystem to provide abort/timeout mechanism. For timeouts, this is the right design, as demonstrated by macOS complications with FUSE. I do wish there was a common way to make things abort.
There was a patch in circulation a long time ago, that could seamlessly switch all open FDs of any given mountpoint into a whole different filesystem named badfs. badfs would just return an error on any operation. As far as I know, that patch never got merged, probably because nobody ever got it working 100%.
That kind of a DoS would require a local attacker, and then the victim to access a mountpoint owned by the attacker. Using FUSE, you could get a lot of processes hanging like that, for sure. I guess you could trap a mail delivery agent, if you still had a system where mail was delivered to users' home directories.
However, forcibly aborting any FUSE mount is a single `echo 1 >/sys/fs/fuse/connection/NNNN/abort`, the only challenge is finding the right ID. (See https://github.com/bazil/fuse/blob/fb710f7dfd05053a3bc9516dd...)
rclone
-
Supabase Storage: now supports the S3 protocol
rclone: a command-line program to manage files on cloud storage.
- World Backup Day
-
S3 Client against disasters (hacks, fires, catastrophes)
Synchronise buckets with Sclone or Rclone
- Show HN: Query Your Sheets with SheetSQL
-
Rclone syncs your files to cloud storage
Says that Apple doesn't provide a multi platform API. It doesn't provide any official supported way to access iCloud from Windows, Linux.
There's a ticket covering everything you might ever want to know:
https://github.com/rclone/rclone/issues/1778
-
Ask HN: Best modern file transfer/synchronization protocol?
seconding rsync and syncthing.
the server could expose an smb or nfs share, the client could mount it, and then sync to that mount.
rsync over ssh also works, if you do not want to run smb/nfs.
this is also a cool tool https://rclone.org/
-
Ask HN: How do you do personal backups in 2023? (Google and Dropbox issues)
rclone [1] to dropbox. works since years without problems
[1] https://rclone.org/
-
Which synchronization tool are you using together with the pCloud Crypto Folder?
rclone provides a special pCloud config option, which makes the setup straight forward. rclone can encrypt the data it uploads with its own encryption but not with the pCloud encryption. Therefore it can only upload data to the unencrypted pCloud folders, not to the Crypto Folder.
- Backup of Google Drive (and photos?) to local disk (not to Google Drive)
-
All I want for Christmas is
The arkclone project impliments rclone in ArkOS to achieve cloud saves. Not yet built in to ArkOS yet, and not a lot of recent traction on the pull request to get it added, but it can be installed manually.