webdavfs icon indicating copy to clipboard operation
webdavfs copied to clipboard

Bug: cache is not updated if the file size has not changed

Open Jipok opened this issue 11 months ago • 2 comments

I'm writing PATCH support for a standard webdav server in go. While I was testing different bytes=A-B, I noticed that if the file size did not change after the operation, then the old version of the file would be displayed on the local file system. You can restart the web server, rewrite the file 100 times on the server or client (but without changing the size), wait a hour, but the client will still have the old version of the file without changes. I also tested dufs to make sure that the problem is not in my implementation. There's a problem there too.

Perhaps I still made a mistake somewhere. But I suggest you check with your webserver too.

Jipok avatar Mar 02 '24 18:03 Jipok

20240302_225958 While I was doing the test example, I noticed that even changing the size does not always reset the cache. As you can see, adding locally to the end of the file using echo did not clear the cache. Only size changes on the server that are not tracked by the webdavfs allow you to see the real file.

Jipok avatar Mar 02 '24 18:03 Jipok

My implementation: https://github.com/Jipok/webdavWithPATCH

I can’t help but say that the PATCH option proposed by SabreDav is redundant. It is not clear why it was necessary to require the range to be specified if Content-Length was available. How and what should the server do if the sizes do not match. The ability to write at an offset from the end of the file seems useless. After all, the only real application of this method is an implementation similar to webdavfs. And for this, a simple indication of the offset from the beginning of the file is enough. That's all. The append mode is actually not needed either.

Jipok avatar Mar 02 '24 18:03 Jipok