starred/floccus

Fork 0

mirror of https://github.com/floccusaddon/floccus.git synced 2026-04-25 14:16:12 +03:00

[GH-ISSUE #1089] Automatic lock override should not happen #723

New issue

Closed

opened 2026-02-25 22:37:55 +03:00 by kerem · 7 comments

kerem commented

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

Owner

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

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

I have seen 4a5e6de29, which reduces the lock-timeout to 15 minutes, and I have my doubts if this is really wise.

I have devices A and B and ~2.5k bookmarks. When doing some major re-organization on device A, i.e. move say delete ~200 bookmarks and move ~200 bookmarks to different folders, I have seen that some the device B takes up to 25 minutes for incorporating these changes. I works, but takes especially more than 15 minutes.
Fearing that another sync run on device A may harm something I disabled synchronization on A manually and waited until B was finished.

Question: What does the 15 minutes lock-timeout mean exactly? Is it overridden after this time? If yes, I don't think such overrides should happen automatically, but only manually (as suggested with #1068).

Expected Behavior

No automatic lock-override at any time.

To Reproduce

None.

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/1089 ### 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 I have seen 4a5e6de29, which reduces the lock-timeout to 15 minutes, and I have my doubts if this is really wise. I have devices A and B and ~2.5k bookmarks. When doing some major re-organization on device A, i.e. move say delete ~200 bookmarks and move ~200 bookmarks to different folders, I have seen that some the device B takes up to 25 minutes for incorporating these changes. I works, but takes especially more than 15 minutes. Fearing that another sync run on device A may harm something I disabled synchronization on A manually and waited until B was finished. Question: What does the 15 minutes lock-timeout mean exactly? Is it overridden after this time? If yes, I don't think such overrides should happen automatically, but only manually (as suggested with #1068). ### Expected Behavior No automatic lock-override at any time. ### To Reproduce None. ### Debug log provided - [ ] I have provided a debug log file

kerem

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

closed this issue
added the
bug
label

kerem commented

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

Author

Owner

@marcelklehr commented on GitHub (Mar 23, 2022):

I have seen 4a5e6de, which reduces the lock-timeout to 15 minutes, and I have my doubts if this is really wise.

Indeed, you are correct. It is not very wise, but was the only idea I had at the time. I am now implementing a proper way to handle this sort of situation. Locks will have a timestamp associated with them in the new implementation, such that while syncing, the lock timestamp will be updated constantly. Only if that timestamp is older than 15min will the lock be overridden.

@marcelklehr commented on GitHub (Mar 23, 2022): > I have seen 4a5e6de, which reduces the lock-timeout to 15 minutes, and I have my doubts if this is really wise. Indeed, you are correct. It is not very wise, but was the only idea I had at the time. I am now implementing a proper way to handle this sort of situation. Locks will have a timestamp associated with them in the new implementation, such that while syncing, the lock timestamp will be updated constantly. Only if that timestamp is older than 15min will the lock be overridden.

kerem commented

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

Author

Owner

@mnalis commented on GitHub (Mar 23, 2022):

one thing to keep in mind (if applicable in this specific case) is that different machines that might be syncing bookmarks might not be NTP-synchronized, e.g. their clocks might differ.

@mnalis commented on GitHub (Mar 23, 2022): one thing to keep in mind (if applicable in this specific case) is that different machines that might be syncing bookmarks might not be NTP-synchronized, e.g. their clocks might differ.

kerem commented

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

Author

Owner

@marcelklehr commented on GitHub (Mar 24, 2022):

different machines that might be syncing bookmarks might not be NTP-synchronized

Damn. Yeah, that's a problem.

There's no good way around this, though, I believe, except somehow asking the server what time it is. @mnalis What do you think? I suppose it's a fair requirement for a sync program to expect accurate time on the involved machines.

@marcelklehr commented on GitHub (Mar 24, 2022): > different machines that might be syncing bookmarks might not be NTP-synchronized Damn. Yeah, that's a problem. There's no good way around this, though, I believe, except somehow asking the server what time it is. @mnalis What do you think? I suppose it's a fair requirement for a sync program to expect accurate time on the involved machines.

kerem commented

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

Author

Owner

@raslop commented on GitHub (Mar 24, 2022):

different machines that might be syncing bookmarks might not be NTP-synchronized

Damn. Yeah, that's a problem.

There's no good way around this, though, I believe, except somehow asking the server what time it is. @mnalis What do you think? I suppose it's a fair requirement for a sync program to expect accurate time on the involved machines.

I also believe that with the help of the server it should be possible for a client B to determine the age of a lock on the server created by client A, even if the clocks are not synchronized, at least with an error margin of several seconds. Let's assume client A is currently synchronizing and regularly refreshes the lock on the server S. Client B checks the lock on the server and can then compare the following four timestamps:

(a) The timestamp of the lock message from A taken from A's local clock. This is directly available as part of the lock/lockfile.
(b) The last modification time of the lock/lockfile from the server S, taken from S's local clock. At least for WebDAV this should be available via PROPFIND or maybe even via the Last-Modified HTTP header (which seems to be optional). I also don't know HTTP response headers are available in floccus.
(c) The current local time on B, taken from B's local clock.
(d) The current local time on S, taken from the Date HTTP header of the response from S.

This is not thought to the end, but maybe a start. At least it should be possible to determine if the clocks are sufficiently synchronized.

I don't know about the google drive backend, but for WebDAV and maybe even for Nextcloud based accounts this could be possible.

I also tend to say that sufficiently synchronized clocks are required for synchronization.

@raslop commented on GitHub (Mar 24, 2022): > > different machines that might be syncing bookmarks might not be NTP-synchronized > > Damn. Yeah, that's a problem. > > There's no good way around this, though, I believe, except somehow asking the server what time it is. @mnalis What do you think? I suppose it's a fair requirement for a sync program to expect accurate time on the involved machines. I also believe that with the help of the server it should be possible for a client B to determine the age of a lock on the server created by client A, even if the clocks are not synchronized, at least with an error margin of several seconds. Let's assume client A is currently synchronizing and regularly refreshes the lock on the server S. Client B checks the lock on the server and can then compare the following four timestamps: - (a) The timestamp of the lock message from A taken from A's local clock. This is directly available as part of the lock/lockfile. - (b) The last modification time of the lock/lockfile from the server S, taken from S's local clock. At least for WebDAV this should be available via PROPFIND or maybe even via the `Last-Modified` HTTP header (which seems to be optional). I also don't know HTTP response headers are available in floccus. - (c) The current local time on B, taken from B's local clock. - (d) The current local time on S, taken from the `Date` HTTP header of the response from S. This is not thought to the end, but maybe a start. At least it should be possible to determine if the clocks are sufficiently synchronized. I don't know about the google drive backend, but for WebDAV and maybe even for Nextcloud based accounts this could be possible. I also tend to say that sufficiently synchronized clocks are required for synchronization.

kerem commented

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

Author

Owner

@marcelklehr commented on GitHub (Mar 25, 2022):

Indeed, it would be best to utilize the server time for this. I didn't know the Date header was mandatory for 2xx - 4xx responses, that's useful!

@marcelklehr commented on GitHub (Mar 25, 2022): Indeed, it would be best to utilize the server time for this. I didn't know the Date header was mandatory for 2xx - 4xx responses, that's useful!

kerem commented

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

Author

Owner

@marcelklehr commented on GitHub (Jun 11, 2023):

We're using the Last-Modified header now which seems to work well. The Date header is not used so far, but I feel like that's fine.

@marcelklehr commented on GitHub (Jun 11, 2023): We're using the Last-Modified header now which seems to work well. The Date header is not used so far, but I feel like that's fine.

kerem commented

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

Author

Owner

@github-actions[bot] commented on GitHub (Jun 11, 2024):

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions[bot] commented on GitHub (Jun 11, 2024): This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

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#723

No description provided.

Rows
Columns