My file system sematics program presented a few days ago is very useful to verify that a file system can work as a unix home directory,and today I had to extend it a bit. I'm looking into alternatives for home directory access here at the University of Oslo, and one of the options is sshfs. My friend Finn-Arne mentioned a while back that they had used sshfs with Debian Edu, but stopped because of problems. I asked today what the problems where, and he mentioned that sshfs failed to handle umask properly. Trying to detect the problem I wrote this addition to my fs testing script:
mode_t touch_get_mode(const char *name, mode_t mode) {
mode_t retval = 0;
int fd = open(name, O_RDWR|O_CREAT|O_LARGEFILE, mode);
if (-1 != fd) {
unlink(name);
struct stat statbuf;
if (-1 != fstat(fd, &statbuf)) {
retval = statbuf.st_mode & 0x1ff;
}
close(fd);
}
return retval;
}
/* Try to detect problem discovered using sshfs */
int test_umask(void) {
printf("info: testing umask effect on file creation\n");
mode_t orig_umask = umask(000);
mode_t newmode;
if (0666 != (newmode = touch_get_mode("foobar", 0666))) {
printf(" error: Wrong file mode %o when creating using mode 666 and umask 000\n",
newmode);
}
umask(007);
if (0660 != (newmode = touch_get_mode("foobar", 0666))) {
printf(" error: Wrong file mode %o when creating using mode 666 and umask 007\n",
newmode);
}
umask (orig_umask);
return 0;
}
int main(int argc, char **argv) {
[...]
test_umask();
return 0;
}
Sure enough. On NFS to a netapp, I get this result:
Testing POSIX/Unix sematics on file system info: testing symlink creation info: testing subdirectory creation info: testing fcntl locking Read-locking 1 byte from 1073741824 Read-locking 510 byte from 1073741826 Unlocking 1 byte from 1073741824 Write-locking 1 byte from 1073741824 Write-locking 510 byte from 1073741826 Unlocking 2 byte from 1073741824 info: testing umask effect on file creation
When mounting the same directory using sshfs, I get this result:
Testing POSIX/Unix sematics on file system info: testing symlink creation info: testing subdirectory creation info: testing fcntl locking Read-locking 1 byte from 1073741824 Read-locking 510 byte from 1073741826 Unlocking 1 byte from 1073741824 Write-locking 1 byte from 1073741824 Write-locking 510 byte from 1073741826 Unlocking 2 byte from 1073741824 info: testing umask effect on file creation error: Wrong file mode 644 when creating using mode 666 and umask 000 error: Wrong file mode 640 when creating using mode 666 and umask 007
So, I can conclude that sshfs is better than smb to a Netapp or a Windows server, but not good enough to be used as a home directory.
Update 2010-08-26: Reported the issue in BTS report #594498
Update 2010-08-27: Michael Gebetsroither report that he found the script so useful that he created a GIT repository and stored it in http://github.com/gebi/fs-test.