open("file",O_CREAT|O_WRONLY|O_EXCL,0444) does not work

[Wolfgang Rohdewald]

Binary package hint: sshfs

of course assuming file does not exist

the above statement works correctly when issued on a local filesystem.

When done on a sshfs mounted file system it always returns errno=13 (permission denied).

This happens while executing svn checkout. I want to check out a working directory on a computer running SCO, and I don't have svn binaries for SCO. That is why I need sshfs.

I don't know whether this is a bug in sshfs or in fuse.

My test program:

#include <fcntl.h>
#include <errno.h>

main() {
        int fd=open("tesfile",O_WRONLY | O_CREAT | O_EXCL, 0444);
        printf("errno=%d\n",errno);
        close(fd);
}
notebook:~$ vi c.c
notebook:~$ cat c.c
#include <fcntl.h>
#include <errno.h>

main() {
        int fd=open("testfile",O_WRONLY | O_CREAT | O_EXCL, 0444);
        printf("errno=%d\n",errno);
        close(fd);
}

[Wolfgang Rohdewald (wolfgang-rohdewald)]

I forgot to mention that the test file is always correctly generated.

[mszeredi (miklos)]

Solved in sshfs-1.3/fuse-2.5.x/linux-2.6.15. Unfortunately Dapper only has fuse-2.4, but should work fine on Edgy.

[Sadrak (ostmann)]

I have the following scenario:

sshfs to mount remote folder
svn to checkout to this folder

the commands:
sshfs $UMLUSER@$UMLSERVER:umlhomedir/$UMLNAME ~/umlhomedir/$UMLNAME -o cache=no,compression=yes,uid=$LUID,gid=$LGID,debug,sshfs_debug,loglevel=debug
svn co svn+ssh://$REPOSERVER/svn/testing ~/umlhomedir/$UMLNAME/witzig

i got following erros:
(process:17010): GLib-CRITICAL **: g_hash_table_lookup: assertion `hash_table != NULL' failed
(process:17010): GLib-CRITICAL **: g_hash_table_insert: assertion `hash_table != NULL' failed
(process:17010): GLib-CRITICAL **: g_hash_table_size: assertion `hash_table != NULL' failed
(process:17010): GLib-CRITICAL **: g_hash_table_foreach_remove: assertion `hash_table != NULL' failed

most time this two errors after the call for LSTAT:
(process:17010): GLib-CRITICAL **: g_hash_table_lookup: assertion `hash_table != NULL' failed
(process:17010): GLib-CRITICAL **: g_hash_table_insert: assertion `hash_table != NULL' failed

i have run sshfs in debugmode, output is attached.

my system is Ubuntu 7.04:

ostmann@d4700:~$ dpkg -l | grep fuse
ii fuse-utils 2.6.3-1ubuntu2 Filesystem in USErspace (utilities)
ii libfuse2 2.6.3-1ubuntu2 Filesystem in USErspace librar
ostmann@d4700:~$ dpkg -l | grep sshfs
ii sshfs 1.6-1 filesystem client based on SSH File Transfer
ostmann@d4700:~$ uname -a
Linux d4700 2.6.20-16-386 #2 Thu Jun 7 20:16:13 UTC 2007 i686 GNU/Linux

Same error on Debian Etch:

intern4:~# dpkg -l | grep fuse
ii fuse-utils 2.5.3-4.4 Filesystem in USErspace (utilities)
ii libfuse2 2.5.3-4.4 Filesystem in USErspace library
intern4:~# dpkg -l | grep sshfs
ii sshfs 1.6-1+b2 filesystem client based on SSH File Transfer
intern4:~# uname -a
Linux intern4 2.6.15-1-686-smp #2 SMP Mon Mar 6 15:34:50 UTC 2006 i686 GNU/Linux

[Sadrak (ostmann)]

i was to fast?

there is a workaround=rename to solve my problem. svn want to move files over another existing file and that is not allowed by the protocoll.

know the checkout works, but the GLib-CRITICAL always occure. dont know why and what they do :-/

[Wolfgang Rohdewald (wolfgang-rohdewald)]

seems finally to be fixed, quoting from the sshfs mailing list:

The sshfs team is happy to announce that this long standing bug is at
last being fixed. From the OpenSSH-4.9 release notes:

  * Added a protocol extension method "<email address hidden>" for
    sftp-server(8) to perform POSIX atomic rename() operations.
    (bz#1400)

Support for this extension is already in the sshfs CVS repository, and
will be released in the not too distant future.

Of course, this will only work if the server is upgraded to
OpenSSH-4.9 or later, otherwise one of the workarounds will have to be
used.

[LimCore (limcore)]

It works fine now (even on sshfs 1.7)
I guess this bug can be closed?
Tested on Ubuntu 7.10 amd64

[Wolfgang Rohdewald (wolfgang-rohdewald)]

On Sonntag, 20. April 2008, LimCore wrote:
> It works fine now (even on sshfs 1.7)
> I guess this bug can be closed?
> Tested on Ubuntu 7.10 amd64
>

yes, thanks

--
Wolfgang

[LimCore (limcore)]

seems to be fixed (for some time now)