sshfs

To reduce power, space and cooling requirements, your company’s file server has been replaced with an embedded NAS. This NAS serves NFS and CIFS on the LAN. To the internet it also provides SFTP (SSH) access and unauthenticated HTTP access to a public subset of its files.

While in the office, you continue to darcs pull and push over NFS. While offsite, you can darcs pull using HTTP, but you can’t “darcs push” because the NAS doesn’t have darcs installed. Even if you could compile darcs for the NAS’s MIPS/uclibc linux environment, it only has 16MB of RAM – not enough for the “darcs apply” process that a darcs push over SSH would run on it.

You use SSHFS to make the NAS repos appear as part of the local filesystem, just as NFS does when you’re in the office. Because Darcs sees this as a local push, it runs “darcs apply” on your laptop instead of on the NAS. This doesn’t require darcs (nor lots of RAM) on the NAS, but it will result in a lot more network traffic.

With darcs 2.10

Clone your repository into a bare repository in your sshfs-mounted directory:

cd /path/to/repo
darcs clone . /path/to/sshfs/mountpoint/repo --no-working-dir --disable-patch-index --no-set-default --complete

You should be able to interact with this new repository without problem.

With darcs 2.8

You will have to export DARCS_SLOPPY_LOCKS before any interaction you have with the sshfs-mounted repository.

Clone your repository into a bare repository in your sshfs-mounted directory:

cd sshfs-mountpoint
export DARCS_SLOPPY_LOCKS=True
darcs get /path/to/repo --no-working-dir

With darcs 2.5 or older

You will have to export DARCS_SLOPPY_LOCKS before any interaction you have with the sshfs-mounted repository.

Suppose that the server’s name is example.com, and the repo you want to push to is /srv/vcs/foo. Your local copy is ~/foo (on your laptop).

$ mkdir ~/vcs
$ sshfs -o workaround=rename example.com:/srv/vcs ~/vcs
$ export DARCS_SLOPPY_LOCKS=True
$ cd ~/foo
$ darcs push --all ~/vcs/foo
Pushing to "/home/twb/vcs/foo"...
Writing inventory 1/1 :
Finished applying...
Synchronizing pristine 1/1
Push successful.
$ fusermount -u ~/vcs

Troubleshooting

read: Connection reset by peer (sshfs)

The SSH server didn’t accept your authentication. Run sftp(1) or ssh(1) to try to find out more. Also look at the logs on the server (e.g. /var/log/auth.log), as that will say *why* access was refused.

$ sftp example.com:/srv/vcs
Connecting to example.com...
Changing to: /srv/vcs
sftp> ls
foo  bar  baz  quux

fusermount: user has no write access to mountpoint (sshfs)

You’re trying to mount something like /srv, which your user is not allowed to do. Either mount somewhere else, or run sshfs as root. The latter is not recommended as root cannot access your ssh-agent, and will not use your .ssh/config and .ssh/id_rsa by default. This makes it fiddly to set up (though once working, you could script it).

darcs: takeLock […]: atomic_create […]: unsupported operation (Function not implemented)

You need to export DARCS_SLOPPY_LOCKS=True (to darcs). This should not happen anymore with darcs 2.10. See http://bugs.darcs.net/issue904.

darcs: […]: renameFile: permission denied (Operation not permitted)

You need to pass -o workaround=rename to sshfs. See http://bugs.darcs.net/issue1182