GNOME Bugzilla – Bug 605619
Problem when copying folders with Nautilus using WebDAV
Last modified: 2010-11-05 11:14:29 UTC
I am writing a WebDAV server ('wsgidav') and noticed that I cannot copy folders with Nautilus. 1. connect to the WebDAV share, open it in Nautilus 2. drag a folder to the Ubuntu Desktop 3. A HTML file is created, where the copied folder should be Happens on Ubuntu 8.04 and 9 Reported user agent: 'gvfs/0.2.5' In the WebDAV log I can see, that Nautilus sends a GET request for the collection. My server generates an HTML response in this case, so that the share can be viewed with a browser. I am pretty sure, that this is OK, according to the spec: http://www.webdav.org/specs/rfc4918.html#rfc.section.9.4 I think, Nautilus should rather send recursive GETs for the single files (or send a COPY or MOVE request, if the target is inside the same WebDAV share) Log snippet, trying to copy the folder '/xeri2' from a mapped webdav drive to the Ubuntu desktop: ... <3612> 192.168.178.28 - tester - [2009-12-27 20:32:21] "PROPFIND /xeri2" length=235, depth=0, elap=0.003sec -> 207 Multistatus <4868> 192.168.178.28 - tester - [2009-12-27 20:32:21] "GET /xeri2" elap=0.002sec -> 200 OK <880> 192.168.178.28 - tester - [2009-12-27 20:32:21] "PROPFIND /xeri2" length=235, depth=0, elap=0.004sec -> 207 Multistatus ... ProblemType: Bug Architecture: i386 Date: Sun Dec 27 21:32:34 2009 DistroRelease: Ubuntu 8.04 ExecutablePath: /usr/bin/nautilus Package: nautilus 1:2.22.5.1-0ubuntu3 PackageArchitecture: i386 ProcEnviron: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: nautilus Uname: Linux 2.6.24-24-generic i686
Same problem here. we tested it on several other clients (Windows, Mac) and the WebDAV Client should never try to do a GET on a collection (aka directory). Instead it should recognize it is copying a directory (resourcetype element should have a child element of "collection" from the propfind) and do a recursive call to get the file contents of that collection. A GET is the proper way to get a file but not a directory (aka collection). This is also documented in the spec. This can be easily replicated by running Apache Jackrabbit, dragging a folder and its contents into it and then dragging them back out. When dragging it out only the "folder" is copied and it is copied as an HTML file not as a directory. Normal actions for a WebDAV server when getting a GET request for a collection is to return an HTML directory/file navigation page. The only time a GET on a directory is normally received is when a WebDAV server is accessed directly from a web browser. Tru WebDAV clients use PropFind and Get only files. I hope this clarifies the issue a little bit.
First of all, happy to find that gnome is developing a WebDAV client. I can confirm that Martin is right and this is incorrect behavior. According to RFC 4918 (http://www.webdav.org/specs/rfc4918.html): -- start quote The semantics of GET are unchanged when applied to a collection, since GET is defined as, "retrieve whatever information (in the form of an entity) is identified by the Request-URI" [RFC2616]. GET, when applied to a collection, may return the contents of an "index.html" resource, a human-readable view of the contents of the collection, or something else altogether. Hence, it is possible that the result of a GET on a collection will bear no correlation to the membership of the collection. -- end quote A client cannot rely on consistent results from a GET on a WebDAV collection across servers. PROPFIND for collections and GET for non-collection resources are defined in the specification. I also tested the behavior of M$ Web Folder in XP and they end up with a folder as expected with all files in it. A recursive PROPFIND --> parse XML --> GET all non-collection resources then PROPFIND on all collections found to get all child resources of the requested resource seems the way to go about this.
I can confirm this also for accessing an Apache mod_dav Share.
Bug #615255 is a dupe of this. This is still an issue in Ubuntu 10.04 (Lucid) Nautilus 2.30.0.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 551339 ***