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.
