[Cyberduck-trac] [Cyberduck] #5816: Failure to list WebDAV directories when a file is locked

[Cyberduck]

#5816: Failure to list WebDAV directories when a file is locked
---------------------------+------------------------
 Reporter:  icrew          |         Owner:  dkocher
     Type:  defect         |        Status:  new
 Priority:  normal         |     Milestone:
Component:  webdav         |       Version:  4.0.1
 Severity:  critical       |    Resolution:
 Keywords:                 |  Architecture:  Intel
 Platform:  Mac OS X 10.6  |
---------------------------+------------------------

Old description:

> We use Cyberduck to access the WebDAV server on the Alfresco's Enterprise
> Content Management solution (see http://www.alfresco.com).
>
> It works really well, unless a file in a directory is locked by Alfresco.
> In that case, the listing of that directory is blank in Cyberduck.  We've
> run traces of the interaction with Wireshark, and it appears that if the
> PROPFIND from the server returns results similar to the following on
> '''any''' single file in a directory, Cyberduck will refuse to list
> '''all''' of the contents of that directory:
>
> {{{
>  <D:response>
>     <D:href>/alfresco/webdav/Data%20Dictionary/.DS_Store</D:href>
>     <D:propstat>
>       <D:prop>
>         <D:displayname>.DS_Store</D:displayname>
>         <D:getcontentlength>6148</D:getcontentlength>
>         <D:getcontenttype>application/octet-stream</D:getcontenttype>
>         <D:resourcetype></D:resourcetype>
>         <D:getlastmodified>Thu, 18 Nov 2010 23:04:47
> GMT</D:getlastmodified>
>         <D:lockdiscovery>
>           <D:activelock>
>             <D:locktype>
>               <D:write/></D:locktype>
>             <D:lockscope>
>               <D:D:exclusive/></D:lockscope>
>             <D:depth>0</D:depth>
>             <D:owner></D:owner>
>             <D:timeout>Infinite</D:timeout>
>             <D:locktoken>
> <D:href>opaquelocktoken:28e080a3-2a77-4f35-a786-af0b984e6929:null</D:href>
>             </D:locktoken>
>           </D:activelock>
>         </D:lockdiscovery>
>       </D:prop>
>       <D:status>HTTP/1.1 200 OK</D:status>
>     </D:propstat>
>   </D:response>
> </D:multistatus>
> }}}
>
> I'd be happy to make the complete Wireshark logs available if that would
> be helpful, but I'd rather not have them posted publicly.  Please contact
> me offline if you'd like me to give them to you.
>
> I've done some experimenting with other WebDAV clients, and have
> discovered the following regarding this problem.
>
> Clients that do exhibit this issue:
> * Cyberduck (3.x, 4.0, 4.0.1, 4.0.2)
> * AnyClient
>
> Several that don't:
> * Cadaver
> * Windows XP built-in client
> * Windows 7 built-in client
> * Mac OS X Finder built-in client
> * Transmit
>
> Thanks,
>
> Ian Crew[[BR]]
> Platform and Services Manager, Research Hub[[BR]]
> Information Services and Technology-Data Services[[BR]]
> University of California, Berkeley[[BR]]
> http://hub.berkeley.edu

New description:

 We use Cyberduck to access the WebDAV server on the Alfresco's Enterprise
 Content Management solution (see http://www.alfresco.com).

 It works really well, unless a file in a directory is locked by Alfresco.
 In that case, the listing of that directory is blank in Cyberduck.  We've
 run traces of the interaction with Wireshark, and it appears that if the
 PROPFIND from the server returns results similar to the following on
 '''any''' single file in a directory, Cyberduck will refuse to list
 '''all''' of the contents of that directory.  By "refuse to list" I mean
 that the directory appears to have nothing in it when you view it in
 Cyberduck, even if you upload a new file using Cyberduck.  No error
 message is displayed or logged.

 {{{
  <D:response>
     <D:href>/alfresco/webdav/Data%20Dictionary/.DS_Store</D:href>
     <D:propstat>
       <D:prop>
         <D:displayname>.DS_Store</D:displayname>
         <D:getcontentlength>6148</D:getcontentlength>
         <D:getcontenttype>application/octet-stream</D:getcontenttype>
         <D:resourcetype></D:resourcetype>
         <D:getlastmodified>Thu, 18 Nov 2010 23:04:47
 GMT</D:getlastmodified>
         <D:lockdiscovery>
           <D:activelock>
             <D:locktype>
               <D:write/></D:locktype>
             <D:lockscope>
               <D:D:exclusive/></D:lockscope>
             <D:depth>0</D:depth>
             <D:owner></D:owner>
             <D:timeout>Infinite</D:timeout>
             <D:locktoken>
 <D:href>opaquelocktoken:28e080a3-2a77-4f35-a786-af0b984e6929:null</D:href>
             </D:locktoken>
           </D:activelock>
         </D:lockdiscovery>
       </D:prop>
       <D:status>HTTP/1.1 200 OK</D:status>
     </D:propstat>
   </D:response>
 </D:multistatus>
 }}}

 I'd be happy to make the complete Wireshark logs available if that would
 be helpful, but I'd rather not have them posted publicly.  Please contact
 me offline if you'd like me to give them to you.

 I've done some experimenting with other WebDAV clients, and have
 discovered the following regarding this problem.

 Clients that do exhibit this issue:
 * Cyberduck (3.x, 4.0, 4.0.1, 4.0.2)
 * AnyClient

 Several that don't:
 * Cadaver
 * Windows XP built-in client
 * Windows 7 built-in client
 * Mac OS X Finder built-in client
 * Transmit

 Thanks,

 Ian Crew[[BR]]
 Platform and Services Manager, Research Hub[[BR]]
 Information Services and Technology-Data Services[[BR]]
 University of California, Berkeley[[BR]]
 http://hub.berkeley.edu

--

Comment (by icrew):

 To clarify one thing

-- 
Ticket URL: <http://trac.cyberduck.ch/ticket/5816#comment:1>
Cyberduck <http://cyberduck.ch>
Open source FTP, SFTP, WebDAV, Cloud Files, Google Docs & Amazon S3 Browser for Mac & Windows.