GNOME Bugzilla – Bug 110532
WebDAV marks new files as existant and refuses to copy
Last modified: 2004-12-22 21:47:04 UTC
Description of Problem: When dropping a new file onto a web folder in Nautilus, it will report that this file already exists, and will offer to replace it or cancel the transaction. Steps to reproduce the problem: 1. Type in URL to WebDAV share, optionally log in 2. Drag and drop any file that doesn't exist there yet Actual Results: A dialog pops up, asking you to replace the existing file or cancel. Whatever you choose, your file won't get copied since replacing fails, too. (The file doesn't exist) Expected Results: Nautilus should copy the file to the WebDAV share. How often does this happen? Every time. Additional Information: I've tested this with the resin web server (get a copy at http://www.caucho.com/) version 2.1.6 and 2.1.8 (latest). Both versions work seamlessly with Win2k and Golive 6 under Windows. Tracing the server operation looks normal, too. So I guess Nautilus gets confused while interpretating the response. If you'd need test accounts, I'd be happy to provide one on my server.
A test account would indeed be nice :) I think I tested webdav once and that it worked properly, but maybe that was with another server
I'll send you URL, login and password right away to teuf@users.sourceforge.net
I also see this bug, will investigate a bit more. I even get a crash in nautilus when I double click on the readme file in the test account and click on the up arrow Trying to copy a file, clicking on Replace and then Cancel copies the file though
This sounds similar to the issue the subversion book lists at http://svnbook.red-bean.com/book.html#svn-app-d-sect-3.3 pasted from page: In general, Nautilus 2 works reasonably well against an autoversioning mod_dav_svn, with the following caveats: ... * When overwriting or creating a file , Nautilus first does a PUT of an empty file, then overwrites it with a second PUT. This creates two Subversion filesystem revisions, rather than one. ...
It seems that your server returns some invalid xml when being sent a PROPFIND request (I don't know anything about webdav, I just looked at the code, so I hope what I'm saying is meaninful :p) According to some debug output, gnome-vfs receives <?xml version="1.0"?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>/webdav/gnomevfs.patch.1</D:href> <D:propstat> </D:propstat> <D:status>HTTP/1.1 404 Not Found</D:status> </D:propstat> </D:multistatus> while it should be something like <?xml version="1.0"?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>/webdav/gnomevfs.patch.1</D:href> <D:propstat> <D:status>HTTP/1.1 404 Not Found</D:status> </D:propstat> </D:response> </D:multistatus> if I read rfc 2518
Reading a bit more the spec, it states: The propstat XML element MUST contain one prop XML element and one status XML element. The contents of the prop XML element MUST only list the names of properties to which the result in the status element applies. So the resin answer is not only invalid XML, it's also out of spec. An answer like: <?xml version="1.0"?> <D:multistatus xmlns:D="DAV:"> <D:response> <D:href>/webdav/gnomevfs.patch.1</D:href> <D:status>HTTP/1.1 404 Not Found</D:status> </D:response> </D:multistatus> may be a valid answer (please forgive my poor understanding of rfc2518), and I'm not sure it would be handled correctly by gnome-vfs. I think the best we can do for now is to issue an error message when we get some invalid xml until we get some answer from resin's developers.
Actually, I got it to work :) Patch (with some small cleanups for the http method) coming
Created attachment 15669 [details] [review] parses HTTP response when it is embedded in an XML answer
I didn't look very deeply at this patch, but it does look okish to me, appart from the spew: + g_print ("%s: file exists\n", G_GNUC_FUNCTION); We should probably still ask the resin developers why they did that though. Maybe they had some reason, and at the very least they might want to fix their server.
They already have been contacted, see http://www.caucho.com/quercus/bugtrack/view.xtp?bugreport_id=1144 I don't know how quickly they'll react though :( This patch shouldn't be seen as a hack to get the http method to work with resin, but as an implementation of a part of rfc 2518 which was lacking until now (HTTP response codes seem to be allowed within the XML code sent, see section 12.9.1 of the aforementioned RFC and below) This happens to work with resin because libxml manages to generate meaningful XML from the broken answer we get
Knowing nothing about the webdav protocol, i think the patch looks good. Do you feel confident in it? If so, check it in. (without the g_print)
I don't know much about webdav (I learnt what I know about it over the week end :p), but his patch shouldn't break things (I haven't had the opportunity to test it against some apache webdav server though, but I don't see how they could break if the server gives us "reasonable" answers)
Committed in HEAD (might be worth committing it in the gnome-2-2 branch also once it has been tested a bit without causing regressions)