Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A currently maintained fork of SSHFS

github.com

Post reply on HN
Print view View original

131–140 of 144 posts

Re: A currently maintained fork of SSHFS

#131

Post by feldrim »

fyrabanks wrote: post #130
feldrim wrote: post #101

> This repository has been archived by the owner on May 26, 2022. It is now read-only. > This project is no longer maintained or developed. Github issue tracking and pull requests have therefore been disabled. The mailing list (see below) is still available for use. If you would like to take over this project, you are welcome to do so. Please fork it and develop the fork for a while. Once there has been 6 months of r…

I have nothing but respect for Nikolaus, and SSHFS is absolutely a cornerstone of IT, but if you think the original project was protecting you from vulnerabilities.. I have a bridge to sell you. I also don't really understand what your last sentence is getting at--I may be daft.

It may be my bad wording. All I am saying is that an archived and unmaintained project leaves the option of fixing bugs and vulnerabilities out. The hope is lost with no effort of fixing. And this is inevitable with current open source models.

Re: A currently maintained fork of SSHFS

#132

Post by remram »

kiririn wrote: post #19

rclone mount is my go-to now for sshfs functionality - better performance, stability and caching options

rclone cannot write to the middle of a file though, without transferring the whole file. That is my main issue with it. Maybe sshfs has the same limitation though.

Re: A currently maintained fork of SSHFS

#133

Post by fyrabanks »

feldrim wrote: post #131
fyrabanks wrote: post #130

Earlier quoted context omitted.

I have nothing but respect for Nikolaus, and SSHFS is absolutely a cornerstone of IT, but if you think the original project was protecting you from vulnerabilities.. I have a bridge to sell you. I also don't really understand what your last sentence is getting at--I may be daft.

It may be my bad wording. All I am saying is that an archived and unmaintained project leaves the option of fixing bugs and vulnerabilities out. The hope is lost with no effort of fixing. And this is inevitable with current open source models.

Yeah, I get what you mean. I'm doubtful, but.. hopefully this turns out OK.

Re: A currently maintained fork of SSHFS

#134

Post by concerned_ctzn »

mbirth wrote: post #125
rsync wrote: post #52

A note … I have transitioned from years of macfuse + sshfs on Mac to just installing the excellent “mountain duck” tool which gives you finder and mount point access to an sftp endpoint. Very nice software and indispensable for me.

Just for the record: for macOS there’s now https://www.fuse-t.org/ which works without a kext (by spawning a local NFS server in the background and having macOS connect to it) and also has a sshfs implementation listed on https://github.com/macos-fuse-t/fuse-t/wiki#sample-filesyste... .

brew tap macos-fuse-t/homebrew-cask; brew install fuse-t-sshfs

Re: A currently maintained fork of SSHFS

#135

Post by qalmakka »

Zambyte wrote: post #62
zitterbewegung wrote: post #34

If you want something in user land and you don't mind emacs there is TRAMP “Transparent Remote (file) Access, Multiple Protocol”. https://www.gnu.org/software/tramp/ I use it a lot when I am accessing files from my server on my MacBook Pro .

My favorite thing about using TRAMP is being able to cd to a directory on a remote system, and then cp a file either from my working directory to my local machine (or another remote!), or from my local machine to the current working directory. Before I started using TRAMP, my flow for this was: SSH to a remote system, locate where I want to copy a file to with cd + ls, kill my SSH session, and then scp or rsync the f…

Couldn't you just use sftp?

Re: A currently maintained fork of SSHFS

#136

Post by Zambyte »

qalmakka wrote: post #135
Zambyte wrote: post #62

Earlier quoted context omitted.

My favorite thing about using TRAMP is being able to cd to a directory on a remote system, and then cp a file either from my working directory to my local machine (or another remote!), or from my local machine to the current working directory. Before I started using TRAMP, my flow for this was: SSH to a remote system, locate where I want to copy a file to with cd + ls, kill my SSH session, and then scp or rsync the f…

Couldn't you just use sftp?

Yes. I've never directly used sftp before, but checking the man page it does seem like it would fit the flow I described well.

Re: A currently maintained fork of SSHFS

#137

Post by Zambyte »

lmm wrote: post #119
Zambyte wrote: post #62

Earlier quoted context omitted.

My favorite thing about using TRAMP is being able to cd to a directory on a remote system, and then cp a file either from my working directory to my local machine (or another remote!), or from my local machine to the current working directory. Before I started using TRAMP, my flow for this was: SSH to a remote system, locate where I want to copy a file to with cd + ls, kill my SSH session, and then scp or rsync the f…

Couldn't you use zmodem or something?

I am not familiar with zmodem, but maybe.

Re: A currently maintained fork of SSHFS

#138

Post by lxgr »

lxgr wrote: post #108
duped wrote: post #74

Earlier quoted context omitted.

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…

> fuse-t is kind of clever in that it spins up a TCP server that transpiles NFS requests into FUSE requests TIL, thank you! I'm really sad about losing native SSHFS capabilities on macOS (via FUSE, due to the kernel extension deprecation/ban). I could even get behind the idea of banning all network file systems, but the fact that I can now use SMB and WebDAV(!), but not the one that I actually use all the time, is qu…

Wow, I gave this a try after work on my personal machine and it's amazing – seems to be more stable than the original thing at a first glance! Thanks again.

Re: A currently maintained fork of SSHFS

#139

Post by halJordan »

Zambyte wrote: post #136
qalmakka wrote: post #135

Earlier quoted context omitted.

Couldn't you just use sftp?

Yes. I've never directly used sftp before, but checking the man page it does seem like it would fit the flow I described well.

Idk when you stopped using scp, but scp has been deprecated, and at least w/openssh, using sftp under the hood for years now. You probably have used it if you've scp'd since 2020.

Re: A currently maintained fork of SSHFS

#140

Post by Zambyte »

halJordan wrote: post #139
Zambyte wrote: post #136

Earlier quoted context omitted.

Yes. I've never directly used sftp before, but checking the man page it does seem like it would fit the flow I described well.

Idk when you stopped using scp, but scp has been deprecated, and at least w/openssh, using sftp under the hood for years now. You probably have used it if you've scp'd since 2020.

My point above was that I was making and killing multiple SSH connections to find where I want to copy a file, and then do the copy. Using SCP with an SFTP backend would still do that.
Post reply on HN