tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 59859] New: Tomcat WebDAV MOVE operation fails on Windows
Date Thu, 14 Jul 2016 19:21:27 GMT

            Bug ID: 59859
           Summary: Tomcat WebDAV MOVE operation fails on Windows
           Product: Tomcat 8
           Version: 8.0.36
          Hardware: PC
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina

Created attachment 34040
reproducer app

The WebDAV MOVE operation doesn't seem to work in tomcat8 or tomcat8.5 (it
works fine in tomcat7) on Windows. Here are some reproduction steps and a
reproducer to show the behavior. Note that this only occurs on Windows; I also
tested on Linux and it works fine there, so I think something is wrong at the
OS/java level here.

Reproduction steps:

1) Install tomcat 8 on Windows
2) Add the webdav role and a user with that role to your conf/tomcat-users.xml
3) Deploy the attached webdav test application (webdavapp.war)
4) Start tomcat and make the following MOVE request:

curl -i -X MOVE --header "Destination:
http://localhost:8080/webdavapp/webdav/hello2.txt" --user "tomcat:tomcat"

5) Observe the 500 response

Actual Results:

HTTP/1.1 500 Internal Server Error
Server: Apache-Coyote/1.1
Cache-Control: private
Expires: Wed, 31 Dec 1969 16:00:00 PST
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 1040
Date: Thu, 14 Jul 2016 22:35:32 GMT
Connection: close

Expected Results (as seen on Linux):

HTTP/1.1 201 Created
Server: Apache-Coyote/1.1
Cache-Control: private
Expires: Wed, 31 Dec 1969 19:00:00 EST
Content-Length: 0
Date: Thu, 14 Jul 2016 18:42:30 GMT

Additional Information:

I did spend some time tracing this in jdb and found that the MOVE is partially successfully copies the resource to the destination and but it is
failing to delete the old resource. I think I tracked the failure down to the
following block within o.a.c.servlets.WebdavServlet.doMove():

1745                if(!resource.isDirectory()) {
1746                    if(!resource.delete()) {
1748                        return false;

The problem occurs in the (o.a.c.webresources.CachedResource) resource.delete()
call; it returns false and doesn't delete the resource for some reason (no
exception is thrown, but the errorState flag is set to 1 on the response).
Furthermore, if you make the same exact call again it will successfully delete
the previously copied destination, copy the original to the destination again,
and then fail to delete the original throwing the 500. I can't understand why
the resource.delete() can fail because it passes through to what ends up being
a o.a.c.webresources.FileResource.delete(). I compared the successful
deletion's FileResource instance to the unsuccessful deletion and the instances
match almost exactly (path's differ which is expected). I'm not sure what could
be at play here unless its at the JVM level.

You are receiving this mail because:
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message