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

Strange behavior with WebDav on QNAP NAS #10593

Closed
cyberduck opened this issue Feb 1, 2019 · 4 comments
Closed

Strange behavior with WebDav on QNAP NAS #10593

cyberduck opened this issue Feb 1, 2019 · 4 comments

Comments

@cyberduck
Copy link
Collaborator

@cyberduck cyberduck commented Feb 1, 2019

08eb462 created the issue

I have a strange behavior when I connect with CyberDuck and MountainDuck to my QNAP NAS via WebDav.

Both programs connect but create an empty folder with the same name as the folder I access. Even when I access sub-folders. Every time I find an empty folder with the same name of the folder in which I am.

CyberDuck gives me an error when I try to access that folder while MountainDuck gives me access but I find it empty.

I tried to connect to a simple WebDav server created on a Centos 7 server and this behavior does not occur.

Do you have any advice?

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 4, 2019

e50b44a commented

I am experiencing very similar behavior (suggesting the same underlying cause) when I try to use the duck command line tool, which fails for me when I try to use the --synchronize option.

Steps to reproduce:

  1. Start with a WebDAV server containing a directory of files and a matching local directory of files
  2. Attempt to synchronize them (nothing should happen if they really do match) using the command: duck -v --synchronize davs://user@host.example.com/path/ ~/local/path/
  3. The verbose output shows a series of HTTP headers that seem to indicate that duck is traversing the files on the WebDAV server in breadth-first fashion, which succeeds until descending into the first directory (let's say it's ...host.example.com/path/dir1/).
  4. While traversing the first directory, the breadth-first scan continues through all the files in dir1/ until it comes to the end and tries a PROPFIND on an imaginary file called dir1/dir1/.
  5. The WebDAV server (rightly) responds with HTTP/1.1 404 Not Found, at which point duck complains with the message Listing directory dir1 failed. Unexpected response (404 Not Found). Please contact your web hosting service provider for assistance.

I hope this helps to identify the problematic code. Let me know if I can assist further.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Mar 4, 2019

e50b44a commented

I should add that the output of duck --version on my Mac is Cyberduck 6.9.4 (30164). I am running Mojave version 10.14.3 (18D109).

My WebDAV server is running on a Synology NAS, so this issue is not isolated to QNAP.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Oct 29, 2019

@dkocher commented

The resource itself should be ignored from the PROPFIND reply. Is this still reproducible in the latest version?

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Oct 30, 2019

08eb462 commented

The issue is no more present (Mountain Duck 3.2.1 and Cyberduck 7.1.1).

Loading

@cyberduck cyberduck closed this Nov 28, 2019
@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.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant