-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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
x/net/webdav: microsoft miniredirector fails setting properties of directories #43929
Comments
I was able to address this in testing by first checking if the file was a directory, then returning forbidden for every patch. That seemed to let it move forward at least. We may want to look at a more abstract way of handling this, but I'll submit a patch for now, since we need this to be fixed for our usecase. |
Some file systems do not allow opening directories with a write flag. The PROPPATCH implementation always opens all files it tries to patch with O_RDWR. When running on Linux with the Dir implementation of FileSystem, this leads to all PROPPATCH calls to a directory failing with an Internal Server Error. Some clients, such as git via the Microsoft Mini Redirector try to patch directories' properties. A server using a Dir FileSystem fails in this situation, which makes it unusable for that entire class of clients. Rather than failing with a Internal Server Error we can instead return Forbidden, which indicates to the client that it's not allowed to patch properties on that file. This patch does so if we fail to open the file, and the error is because of a lack of permission, or because the file is a directory. We don't unconditionally return Forbidden in this case because other errors are more likey to be ephemeral: a client retrying could possibly succeed in a subsequent patch. Fixes golang/go#43929
Some file systems do not allow opening directories with a write flag. The PROPPATCH implementation always opens all files it tries to patch with O_RDWR. When running on Linux with the Dir implementation of FileSystem, this leads to all PROPPATCH calls to a directory failing with an Internal Server Error. Some clients, such as git via the Microsoft Mini Redirector try to patch directories' properties. A server using a Dir FileSystem fails in this situation, which makes it unusable for that entire class of clients. Rather than failing with a Internal Server Error we can instead return Forbidden, which indicates to the client that it's not allowed to patch properties on that file. This patch does so if we fail to open the file, and the error is because of a lack of permission, or because the file is a directory. We don't unconditionally return Forbidden in this case because other errors are more likey to be ephemeral: a client retrying could possibly succeed in a subsequent patch. Fixes golang/go#43929
Change https://golang.org/cl/286992 mentions this issue: |
This has come up with Rclone already returns EPERM when you try to open a directory Read/Write and Windows seems to accept that as OK as it doesn't report an error. However it makes a nasty ERROR in the log. Your patch looks like it will solve our problem too. Did you try your webdav implementation with the Windows explorer? |
@ncw awesome, I'm glad to hear it'll fix the problem for you! I tested using both linux davfs2 and Windows Explorer (via map network drive). The issue was only present when using Windows Explorer. With my patch in place, the issue did not occur at all. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Ran a simple wrapper around x/net/webdav. Pointed the windows mini redirector (from windows 10) at it, then tried to clone golang/net:
git clone https://github.com/golang/net.git
What did you expect to see?
The git clone succeed.
What did you see instead?
Digging in, it's clear that the issue is due to windows trying to set properties directories such as
./.git
.I added some logging to the proppatch handler and found it doing these operations:
The text was updated successfully, but these errors were encountered: