Index of /~too/sw/stfufs

[ICO]NameLast modifiedSizeDescription

[DIR]Parent Directory  -  
[   ]ChangeLog01-Feb-2008 19:19 1.8K 
[TXT]Changes-1.0-1.1.html11-Jun-2012 09:33 78K 
[TXT]Changes-1.0rc1-1.0.html20-Jan-2008 22:24 54K 
[TXT]Changes-1.1-1.2.html11-Jun-2012 09:33 134K 
[TXT]FAQv0.rst16-Jan-2008 23:03 79  
[TXT]diffa.sh11-Jun-2012 09:34 4.7K 
[   ]stfufs-1.0.tar.gz19-Jan-2008 14:51 34K 
[   ]stfufs-1.1.tar.gz20-Jan-2008 22:23 34K 
[   ]stfufs-1.2.tar.gz01-Feb-2008 19:18 36K 
[DIR]stfufs-1.2/01-Feb-2008 19:17 -  

Simple TCP FUSE File System

Simple TCP FUSE File System


Very brief for now, more to come if there is enough interest.

Check new development at ../utfs

Note: Communication protocol in 1.2 is incompatible with older verions. Connection attempt will fail if using mixed versions.

Server end may have versions 1.1 and 1.2 installed at the same time if 1.1 is installed when 1.2 is being installed. If this is the case, both 1.1 client and 1.2 client can connect to stfufs server.

Brief Intro

Simple TCP File System is a FUSE (Filesystem in Userspace) based networked file system. It consists of 2 parts. A network server daemon that is started on the (remote) host and a FUSE module running in user-space on the local host. Server component is launched via SSH and after client and server have communicated and created separate TCP connection for data transfer SSH link is shut down.

So, this provides somewhat the same functionality than sshfs, but security traded for speed. If security is not an issue, this is useful at least in the following situations: 1) Either machine is low-end. 2) The machines has important high-load application(s) running. 3) One wants to see real statvfs values ;)

This is one of the first versions. There is lot to improve. New versions may come.


GPL v2 or later


Client requires FUSE headers and libraries, server does not. Currently C99-capable compiler is needed to compile both client and server, but with little effort on the code, this requirement can be removed from the server component.

To compile both client and server, enter make all.

Enter make client or make server to compile either component.

For developers/testers: Enter make debug to compile debug build.

After client compilation on "local" machine (where directory is to be mounted) and server compilation on "remote" machine (from where directory is mounted), install client and server by using command make install PREFIX=<prefix>. Components will be installed in directories PREFIX/bin and PREFIX/lib/stfufs. Make sure PREFIX/bin is in your PATH.


In it's basic form, the usage is pretty same as with sshfs:

stfufs remote:[directory] mountpoint

This instructs server try to bind on ports in range 13668 - 14658, on 10 port increment and if succeeds to bind on any, listen for client to connect on that port. For this to work, one must not have firewall to block on these ports; stfufs-server do know when port is already in use, but does not know about firewall blocking connections. Today, most of the systems (linux distributions, at least) have firewall blocking connections, so check with your system firewall configuration tool how to open the required port(s)

You can also define what port to use for connection:

stfufs -c <portno> remote:[directory] mountpoint

Now server tries to bind on given port and if succeeds, listens for client to connect. The above firewall rules apply.

There is also possibility to make the connection other way around:

stfufs -b <portno> remote:[directory] mountpoint

Now client tries to bind on given port and if succeeds, listens for server to connect. The same firewall rules apply, now on client machine

In both connection directions, there is also a proxy option available. If this sounds too difficult/badly documented, skip over.


./stfufs -c 2001 -p -d usr

This informs server to bind on port 2001, but connection is made to localhost ( port 2000. On that port, there is proxy pre-configured to connect to port 2001 on remote machine. This has currently mostly used for debugging purposes but there might be other uses as well.

And, for another direction:

./stfufs -b 2001 -p -d usr

Now client binds to port 2001, server is instructed to connect to (where proxy is configured to connect to

Not more on these (tricky) issues for now. In most cases the proxyless versions work fine.


(Move this part to developer documentation)

There has been many bugs that has been squashed in this program after some testing. No-one can ever be sure that all bugs are gone, since there is no resources to do indefinite testing.

I've so far done some basic testing with devel/test*.sh functions. Then I tarred usr/bin/\*, which created 95M archive. tar -zdf verified all ok. And, for heavy stfufs buffer runs, I've run while ls -l usr/bin; do :; done for some time..

More tests needs to be developed for more certainty everyhing works fine -- and for regression testing when new releases are made. I'll investigate in this (slowly, though); suggestions for tools/methods are greatly appreciated.


protocol docs
caching (single element is there now, maybe more, client/server side stuff)
more docs in general
protocol updates for smarter stuff
pretocol using stfufs-buffer code (maybe)
split client code out of stfufs binary, to make "reverse" mount possible.


Send comments and suggestions (and bug reports/patches) to too at iki dot fi