Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Failure to list WebDAV directories when a file is locked #5816

Closed
cyberduck opened this issue Mar 22, 2011 · 6 comments
Closed

Failure to list WebDAV directories when a file is locked #5816

cyberduck opened this issue Mar 22, 2011 · 6 comments
Assignees
@dkocher
Labels
bug thirdparty Issue caused by third party webdav WebDAV Protocol Implementation
Milestone
4.1

Comments

@cyberduck
Copy link
Collaborator

5066faa created the issue

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

Platform and Services Manager, Research Hub

Information Services and Technology-Data Services

University of California, Berkeley

http://hub.berkeley.edu
@cyberduck
Copy link
Collaborator Author

5066faa commented

To clarify one thing

@cyberduck
Copy link
Collaborator Author

@dkocher commented

I have been working on Sardine as a replacement for the current WebDAV protocol implementation in Cyberduck. I'll let you know when a snapshot build is ready for testing and we will debug further then if the issue is still open.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Please test with the latest snapshot build (7741b8e or later) available shortly.

@cyberduck
Copy link
Collaborator Author

5066faa commented

Thanks for the update. I just tried it with version 4.0.3 (8692), and I'm still seeing the issue.

There is a change, though: It shows a little red do-not-enter symbol on an affected directory sometimes. It sort of comes and goes when I try to double-click into the folder--sometimes it shows up, sometimes it doesn't. A portion of the times when it's showing, I can't open the directory, but sometimes I can.

When I can open the folder, unfortunately I still don't see any contents.

BTW, We're actually hoping that it'll end up working like Cadaver/Windows/Mac/Transmit, in that the user will be allowed to click into the folder, and will see the contents of that folder....from what (little) we've been able to establish, that's what should be happening.

Thanks again for your work on this, and please do let me know if there's anything else I can do to help!

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Looking closer at this response it looks like it is not well formed. <D:lockscope><D:D:exclusive/></D:lockscope> is not valid.

Element type "D:D" must be followed by either attribute specifications, ">" or "/>".

Can you please report this issue to the server vendor.

@cyberduck
Copy link
Collaborator Author

5066faa commented

Just a quick note to say thanks for your help on this. You were right--it was a bug in Alfresco.

Some details, in case anyone else runs across this:

It turns out that this mal-formed XML was due to a bug in Alfresco version 3.3.3 (and possibly prior to that). Upgrading to 3.3.4 or later fixes the bug, but it may be necessary--it was in my case--to use a script to go through and manually delete the locks that were created prior to version 3.3.4.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@dkocher dkocher

Labels
bug thirdparty Issue caused by third party webdav WebDAV Protocol Implementation
Projects
None yet
Milestone
4.1
Development

No branches or pull requests
2 participants
@dkocher @cyberduck