starred/floccus

Fork 0

mirror of https://github.com/floccusaddon/floccus.git synced 2026-04-26 14:45:59 +03:00

[GH-ISSUE #1087] Race condition when acquiring lock for webdav based accounts #720

New issue

Open

opened 2026-02-25 22:37:54 +03:00 by kerem · 0 comments

kerem commented

2026-02-25 22:37:54 +03:00

Owner

Originally created by @raslop on GitHub (Mar 22, 2022).
Original GitHub issue: https://github.com/floccusaddon/floccus/issues/1087

Which version of floccus are you using?

4.12.0

Sync method

{"label"=>"WebDAV"}

Which browser are you using?

Firefox 98.0.1

Which version of Nextcloud Bookmarks are you using? (if relevant)

No response

Which version of Nextcloud? (if relevant)

No response

What kind of WebDAV server are you using? (if relevant)

Doesn't matter.

Describe the Bug

A typical sync cycle looks like this in the logfile of a webdav server:

2022-03-22T12:36:01.904401Z ip1 bob 404 GET /bookmarks/bookmarks.xbel.lock
2022-03-22T12:36:02.057273Z ip1 bob 201 PUT /bookmarks/bookmarks.xbel.lock
2022-03-22T12:36:02.250949Z ip1 bob 200 GET /bookmarks/bookmarks.xbel
2022-03-22T12:36:06.100949Z ip1 bob 200 PUT /bookmarks/bookmarks.xbel
2022-03-22T12:36:06.791755Z ip1 bob 204 DELETE /bookmarks/bookmarks.xbel.lock

The first GET request for the .lock file seems too check if that account is currently locked and the following PUT seems to actually lock the account, it it was unlocked (404 response).
There is a race condition (here approx. 150ms). When a second client does the same GET for checking for the .lock file before the PUT for the .lock file of the first client both think nothing is locked and do the .lock file PUT. If both have changes, the slower one will win, as this PUT for the data request happens later and will overwrite the changes of the faster client.

To solve this the GET and PUT for the .lock file must be done atomically. WebDAV has the LOCK method,) which, if used, should solve the issue, right?

Expected Behavior

No race condition.

To Reproduce

Didn't try to reproduce, just thought about it so far.

Debug log provided

I have provided a debug log file

Originally created by @raslop on GitHub (Mar 22, 2022). Original GitHub issue: https://github.com/floccusaddon/floccus/issues/1087 ### Which version of floccus are you using? 4.12.0 ### Sync method {"label"=>"WebDAV"} ### Which browser are you using? Firefox 98.0.1 ### Which version of Nextcloud Bookmarks are you using? (if relevant) _No response_ ### Which version of Nextcloud? (if relevant) _No response_ ### What kind of WebDAV server are you using? (if relevant) Doesn't matter. ### Describe the Bug A typical sync cycle looks like this in the logfile of a webdav server: ``` 2022-03-22T12:36:01.904401Z ip1 bob 404 GET /bookmarks/bookmarks.xbel.lock 2022-03-22T12:36:02.057273Z ip1 bob 201 PUT /bookmarks/bookmarks.xbel.lock 2022-03-22T12:36:02.250949Z ip1 bob 200 GET /bookmarks/bookmarks.xbel 2022-03-22T12:36:06.100949Z ip1 bob 200 PUT /bookmarks/bookmarks.xbel 2022-03-22T12:36:06.791755Z ip1 bob 204 DELETE /bookmarks/bookmarks.xbel.lock ``` The first `GET` request for the `.lock` file seems too check if that account is currently locked and the following `PUT` seems to actually lock the account, it it was unlocked (404 response). There is a race condition (here approx. 150ms). When a second client does the same `GET` for checking for the `.lock` file before the `PUT` for the `.lock` file of the first client both think nothing is locked and do the `.lock` file `PUT`. If both have changes, the slower one will win, as this `PUT` for the data request happens later and will overwrite the changes of the faster client. To solve this the `GET` and `PUT` for the `.lock` file must be done atomically. WebDAV has the [`LOCK` method](https://datatracker.ietf.org/doc/html/rfc4918#section-9.10),) which, if used, should solve the issue, right? ### Expected Behavior No race condition. ### To Reproduce Didn't try to reproduce, just thought about it so far. ### Debug log provided - [ ] I have provided a debug log file

kerem added the

bug

label

2026-02-25 22:37:54 +03:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/floccus#720

No description provided.

Rows
Columns