Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
newest neon has a ssl option for gnutls (openssl is
*incompatible* with the GPL licence)
Logged In: YES
will take some time. I just added support for neon 0.25. As
supporting too many different library versions is a mess, I
think I will not upgrade before Debian packages neon 0.26.
Logged In: YES
Under Gentoo it's not possible to install both subversion
and davfs2, b/c subversion needs neon-0.26 :-(
I have just updated davfs2-1.0.2 in our CVS repository to
sopport neon 0.2.6. You may get it from the repository by
Just hit Enter when asked for your password.
"$ cvs -z3
checkout -r v1 -P davfs2"
Please don't forget "-r v1" to get the correct version.
The sources should now be in a directory named "davfs2".
It is tested with neon 0.2.6 and openssl, but not with
gnutls. It would be nice if you could test it and send me a
report (but I will be short of time for the next two weeks,
so answers may be slow).
Thanks for your work, Gentoo now has a stable davfs2 again
beside subversion, bugzilla history can be found here :
the new release davfs2 1.1.1 should fix the serious bugs
that are in the CVS version used by Gentoo. It supports neon
It would be nice to receive some test reports, so I could do
a bug fixed version in about two weeks, to get a real stable
version of davfs2.
first view : compiles, installs and works fine, some minor
If the mount is called as a non-root user I get:
tfoerste@n22 ~ $ mount /mnt/dav_cps
/sbin/mount.davfs: You can't mount into another users home
"/" is the home directory of nobody.
but I don't understand that message b/c I have:
n22 /home/tfoerste # ls -ld / /mnt /mnt/dav_cps
drwxr-xr-x 22 root root 4096 Sep 14 23:13 /
drwxr-xr-x 18 root root 4096 Sep 20 14:25 /mnt
drwxr-xr-x 2 root root 4096 Oct 2 2005 /mnt/dav_cps
The other thing is that for a (very) lame remote davfs
server I get during mount:
/sbin/mount.davfs: Connection failed, mounting anyway. File
system will only be usable when connection comes up.
But an immediately command like ls, cd ... works w/o
problems (but it is very slow, as I said)
I asked the Gentoo maintainer for an official test ebuild
for that, b/c my try to produce a working ebuild failed.
thanks for the report.
"/" is the home directory of nobody:
The same problem is reported by other users.
I will have to change the message into "...user nobody". It
As mounting a resource from a remote webdav server might be
even more dangerous than mounting a CDROM (?), I felt the
need to put additional restrictions on user mounts (that are
not allready demanded by mount). One restriction is, that a
user must not use a mountpoint that lies in the home
directory of somebody else.
Unfortunately gentoo makes the file system root "/" the home
directory of user nobody, so almost everthing belongs to the
home directory of user nobody.
I believe this is a bad choice by gentoo. Maybe you can get
some information about the reasons for this. On my Debian
Sarge system the home directory of nobody is "/nonexistent",
which does not exist. Nobody never complained about this.
Connection failed, mounting anyway:
I believe this is mostly caused by slow DNS look up. The
problem: When the first request fails, mount.davfs does not
know whether it will succeed the next time, or the problem
turns out to be permanent. So I felt the need to inform the
user about this.
I believe it would not be a good idea, for instance, to try
a fixed number of times, and then to exit if the connection
does not came up. Its hard to find the right number of
retries, and some users like to mount even if they know the
server is down, but will come up tomorrow.
Have you any suggestions for a better message. Or do you
think the message is not necessary at all?
thanks for the comprehensive answer. regarding "/" I filed a
bug at Gentoo, but the opinion of the devs differs from your.
Here is the link to the bugzilla page :
BTW, under AIX I found:
I solved the issue by changing my /etc/passwd for nobody.
Regarding the slow network connection: You're right. There's
no general rule how to handle this. I think, the current
behaviour is ok althought I was a ölittle bit confused b/c
the msg appears immediately after the mount command.