I remember using SSHFS way back in the day on Mac, also back then thinking "SSHFS" meant "SSH + HFS." It was always confusing to grab the right tools for it, and it never worked very well. With remote codebases, I just SSH in and edit in Vim.
A currently maintained fork of SSHFS
81–90 of 144 posts
Re: A currently maintained fork of SSHFS
#82Earlier quoted context omitted.
This is nothing extraordinary. I don't know why this is a tradition, but this is a very typical situation for C projects.
Compilation used to be slower, and one 5K line file would be noticeably faster than 10 500 line files, not to mention possibly having to build extra header files to connect them together. That would encourage larger files.
As a n00b, I enjoyed libs with everything in one file cause I didn't know how to drop the lib into my codebase and build otherwise. Like how was I supposed to merge their makefile into mine, I dunno. And my code was in one file cause I was too lazy to mess with .h files.
Re: A currently maintained fork of SSHFS
#83Discovered that you can replace sshfs with rclone. And the project appear to be way more active : https://github.com/rclone/rclone Edit: cf: https://rclone.org/commands/rclone_mount/
Unfortunately `rclone mount` doesn't support symlinks yet: it always deferences their contents. In contrast, SSHFS has options to either dereference them, or to use them as-is, or to transform absolute links into relative links (which may be more likely to resolve on the client)
Re: A currently maintained fork of SSHFS
#84Nautilus (Ubuntu's file explorer) allows to mount SFTP folders. Supposedly it uses `gvfs` under the hood. Note that SFTP uses an SSH connection for its file transfers, so I have not seen an UI difference from SSHFS
It allows you to browse sftp endpoints in the nautilus GUI but does it simultaneously create a mount point in the file system that you could use in the terminal? I don’t remember…
You can use the `gio mount` command to mount a given remote. It will appear as a folder in `/run/user/$UID/gvfs`.
As an example, my phone has some systemd services which run `gio mount` for an SMB share and an SFTP share, when I'm connected to my home WiFi. I've got symlinks in my home folder to their associated gvfs directories, which become dangling when I'm not at home.
Re: A currently maintained fork of SSHFS
#85Earlier quoted context omitted.
Does the FUSE mount work on OSX?
VFS on MacOS is a minefield. You either need to use a kext (bad option, for many reasons), a network file system (NFS or SMB) and pretend your VFS is a remote server, or create a FileProvider system extension (which cannot actually function as a VFS). If your workflow relies on a VFS that isn't NFS/SMB then don't use MacOS. fuse-t is kind of clever in that it spins up a TCP server that transpiles NFS requests into FU…
>but it comes with a bit of a cost and eats a TCP port
I have never heard of someone running out of TCP ports on a personal computer since, well, the invention of TCP on personal computers.
Re: A currently maintained fork of SSHFS
#86Unfortunately, this fork does not look very vivid. Last commit in March, almost not activity in terms of PRs and issues. I would not bet on it.
What sort of activity level are you expecting from a stable project?
plus, they are investigating old edgy errors in many issues, rescuing them (already closed) from the old project.
Re: A currently maintained fork of SSHFS
#87Earlier quoted context omitted.
It does seem like a good fit for the maintainers of openssh. I too had thought it was key linux ssh infrastructure.
I kinda doubt it, SSH already have SFTP and SSHFS is .... quite honestly a tool that has no business existing. It's a neat trick but it's always going to be something that someone bolted on to a solution because they didn't want to deal with a proper file server. Part of the appeal might be that NFS (3 or 4, take your pick) is still the best we've been able to come up with and neither is really that great for basic i…
SSHFS provides enormous value precisely because it doesn't rely on configuring a file server or elevated privileges. It's convenient, secure and performs well. The ability to create ad hoc mounts for any remote location I can access via SSH is awesome (though I prefer rsync or scp for file transfers).
But relying on SSHFS in production... Yeah, that's insane.
Re: A currently maintained fork of SSHFS
#88Earlier quoted context omitted.
Wasabi might been a good choice for you on that front
Backblaze B2 is $5/TB/month, Hetzner is $4.08/TB/month for 1TB, Wasabi is $6.99/TB/month Wasabi seems like the most expensive here, with the caveat that Hetzner requires ordering discrete steps of storage rather than the 'pay-as-you-go' model of the other two
Doesn't Hetzner storage boxes also have lower redundancy guarantees? It's been a while since I've looked, so not sure - it's not obvious from their ordering page. They're great either way, though, especially given the "unlimited" egress.
Re: A currently maintained fork of SSHFS
#89Earlier quoted context omitted.
I mostly care if projects don't accept bugfixes. For example "inotify feature longer works with the latest glibc release due to subtle API change" might be an easy 10 line pull request to fix. But if the maintainer doesn't take the pull request and make a release, then the effort of fixing it is wasted, and every single user has to workaround/suffer from that bug into the future. There are loads of projects in that s…
I wish github and other code hosters made it easier to "just make a release". Next to the "Download zip" button on github, they should add a "Download built .deb" and "Download built .exe" - and those buttons should work on any fork, branch, PR, etc. And they should add all the necessary build infrastructure to achieve that. It turns out that at scale, build infrastructure is pretty cheap to run, since caching is so…
That sounds more like papering over the cracks of legacy systems, introducing even more centralisation and power to a handful of unaccountable "hosters", and placing even more responsibilities on maintainers (who may be AWOL).
- Cryptographically-verified, content-addressed storage (e.g. IPFS) is preferable to downloading random EXEs from "github and other code hosters". Indeed, for sources too! (I learned this lesson when Microsoft bought GitHub, and many projects jumped ship; that caused an outbreak of 404s for anything that was hard-coding github.com URLs!)
- Rather than relying on someone else having produced opaque blobs for us, it's better for everyone to be capable of building things, if needed. Nix (and Guix) are good for this, since they're source-based, ensuring that the full build instructions are available (they will automatically download binaries, if available and signed by a trusted key; but the option of building ourselves is always there). This is also crucial if we want to validate those binaries for ourselves (I recall the "trustix" project is trying to crowd-source such validation too)
- Another advantage of the Nix/Guix approach is that build instructions can be parameterised, e.g. by the source. This allows anyone to plug in any version of the code they like (whether a git commit, or a local folder, or an IPFS URL, etc.). Again, if someone else has already built that combination (and someone we trust has signed it) then their existing binary will be fetched.
This sort of approach doesn't require any buy-in from hosting platforms, maintainers, DNS authorities, etc.
Re: A currently maintained fork of SSHFS
#90Earlier quoted context omitted.
Not just rclone, but it seems that so many things are moving away from using the ssh_config; I have things setup to "just work" for so many hosts with OpenSSH, and having to individually configure a half-dozen programs that build on top of SSH is a pain. Sometimes it's because they use paramiko, other times it's because they want to pass their own configuration options to ssh that mess things up. Sometimes you can ma…
Can you name these programs? I want to add them to my 'painful' list.
jetbrains products. I think they've improved their situation, but it's still a little quirky