What version of Go are you using (go version)?

go version go1.15 linux/amd64

Does this issue reproduce with the latest release?

I haven't tried yet, but the relevant code does not seem to have changed.

What operating system and processor architecture are you using (go env)?

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/kyle/.cache/go-build"
GOENV="/home/kyle/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/kyle/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/kyle/"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build077298422=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I'm using https://github.com/hacdias/webdav to evaluate a few things. I plan on implementing my own server using the webdav library soon, but wanted to get some testing done on it before diving in. While testing (using davfs2 as a client), I noticed that if I did the following, the third operation would always fail.

touch foo.txt && rm foo.txt && touch foo.txt
touch: cannot touch 'foo.txt': Permission denied

The requests/responses issued by davfs2/returned by webdav are:

1. PROPFIND / -> 207
2. LOCK foo.txt -> 201
3. HEAD /foo.txt -> 200
4. DELETE /foo.txt -> 204
5. LOCK /foo.txt -> 423
6. PROFIND /foo.txt -> 404

If I wait for a bit between when I create the file and delete it, everything works fine. It looks to me like davfs2 creates the lock, but does not flush the contents of the file/release the lock until some time expires. If I remove the file before that time expires, davfs2 issues the DELETE without releasing the lock. The problem is that despite the file not existing, the webdav server still thinks that a lock is present for the file, so it refuses to lock it again in step 5.

Perhaps davfs2 should release the lock. But, the webdav RFC is pretty clear that the lock should be released when the file is deleted:

   A server processing a successful DELETE request:

   MUST destroy locks rooted on the deleted resource

Detailed reproduction steps:

1. Compile https://github.com/hacdias/webdav
2. Run the following:

cd $(mktemp -d)
cat > config.yaml <<EOF 
# Server related settings
address: 127.0.0.1
port: 8080
auth: false
tls: false
prefix: /

scope: .
modify: true
rules: []
EOF

webdav -p 8080 --auth=false

3. Download/build/install/etc cadaver
4. Run cadaver http://localhost:8080
5. In its command prompt, run the following commands:

lock foo.txt
rm foo.txt
lock foo.txt

6. Note that the third operation fails with 423 Locked. It should have succeeded.

What did you expect to see?

dav:/> lock foo.txt
Locking `foo.txt': succeeded.
dav:/> rm foo.txt
Deleting `foo.txt': succeeded.
dav:/> lock foo.txt
Locking `foo.txt': succeeded.
dav:/> 

What did you see instead?

dav:/> lock foo.txt
Locking `foo.txt': succeeded.
dav:/> rm foo.txt
Deleting `foo.txt': succeeded.
dav:/> lock foo.txt
Locking `foo.txt': failed:
423 Locked
dav:/>