mirror of
https://github.com/floccusaddon/floccus.git
synced 2026-04-26 14:45:59 +03:00
[GH-ISSUE #1607] Brave tab sync keeps .lock #1058
Labels
No labels
browser-specific
bug
correctness issues
enhancement
feature: Google Drive
feature: Linkwarden
feature: git
feature: nextcloud-bookmarks
feature: tabs
feature: webdav
help wanted
native-app
priority: high
priority: low
priority: medium
pull-request
question
question
stale
upstream
waiting for more information
wontfix
🙁 Not following issue template
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/floccus#1058
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @andbenn on GitHub (May 12, 2024).
Original GitHub issue: https://github.com/floccusaddon/floccus/issues/1607
Which version of floccus are you using?
5.1.1
How many bookmarks do you have, roughly?
12 tabs
Are you using other means to sync bookmarks in parallel to floccus?
no
Sync method
WebDAV
Which browser are you using? In case you are using the phone App, specify the Android or iOS version and device please.
fastmail
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)
Fastmail's webdav service
Describe the Bug
Brave has a unique profile that only it uses to sync tabs to Fastmail's webdav service.
Since floccus was updated to 5.1.1 2-3 days ago, I've had two persistent .lock files appear. Each time I've renamed both files then pushed my current tabs back to the server.
My Firefox also has floccus 5.1.1, but does not appear to have .lock files hanging around like Brave does.
I wonder if I should also reset the cache on the floccus tabs setting page when these lock files won't go away.
3 persistent tag profile lock files on Brave in a day.
Expected Behavior
No lock files longer than a few minutes. :)
I have another computer with Brave and floccus 5.1.1. Currently running. Will see if locks appear in that tab parofile.
To Reproduce
Current Brave, 1.65.132
Floccus 5.1.1
Tab profile, fastmail webdav service
Tab profile is unique to each computer of mine. No cross computer tab sharing (but bookmarks)
Debug log provided
@github-actions[bot] commented on GitHub (May 12, 2024):
Hello 👋
Thank you for taking the time to open this issue with floccus. I know it's frustrating when software
causes problems. You have made the right choice to come here and open an issue to make sure your problem gets looked at
and if possible solved.
I'm Marcel and I created floccus and have been maintaining it ever since.
I currently work for Nextcloud which leaves me with less time for side projects like this one
than I used to have.
I still try to answer all issues and if possible fix all bugs here, but it sometimes takes a while until I get to it.
Until then, please be patient.
Note also that GitHub is a place where people meet to make software better together. Nobody here is under any obligation
to help you, solve your problems or deliver on any expectations or demands you may have, but if enough people come together we can
collaborate to make this software better. For everyone.
Thus, if you can, you could also have a look at other issues to see whether you can help other people with your knowledge
and experience. If you have coding experience it would also be awesome if you could step up to dive into the code and
try to fix the odd bug yourself. Everyone will be thankful for extra helping hands!
One last word: If you feel, at any point, like you need to vent, this is not the place for it; you can go to the forum,
to twitter or somewhere else. But this is a technical issue tracker, so please make sure to
focus on the tech and keep your opinions to yourself.
I look forward to working with you on this issue
Cheers 💙
@andbenn commented on GitHub (May 12, 2024):
Meh, As I leave my desktop on, woke up to a Brave tab profile lock again. That's three. Something's amiss. Should I wipe out the remote files and clear the foccus cache? Or other advice? If you want a log, I'll run one.
@marcelklehr commented on GitHub (May 13, 2024):
I'll try to reproduce later today and see if I can fix something
@andbenn commented on GitHub (May 13, 2024):
No rush from me. Prioritize as you need. You probably have a ton of work going on. I can hold for a while. Thank you!
@marcelklehr commented on GitHub (May 16, 2024):
Can't reproduce :/ Can you send me some logs from this?
@marcelklehr commented on GitHub (May 16, 2024):
Since v5.1.1 floccus should not anymore reset the lock after it has been removed :/
@andbenn commented on GitHub (May 16, 2024):
I've got another issue with this browser at the moment. Floccus extension is 5.1.2. I have a bookmark and tab profiles to sync every 15 minutes. The check is present in the extension bar. The profiles are "(check) All Good", but reported the "last synchronization 2 days ago".
If I change the interval, in hopes that such would trigger a sync, nothing happens. This browser needs a reset.
@marcelklehr commented on GitHub (May 16, 2024):
Try updating floccus first, v5.1.2 had a faulty build that wouldn't sync anymore.
@andbenn commented on GitHub (May 16, 2024):
I might have had the bad 5.1.2. Removed 5.1.2 from my browsers, re-installed from the extension stores, and imported my backup profiles.
I also turned on error reporting, and auto-sync. Since doing that an hour ago, the pesky Brave browser now has it's tabs profile Scheduled and I see a .lock in my webdav storage for that profile. Hopefully you'll get some anonymized error reporting. Thanks!
@marcelklehr commented on GitHub (May 17, 2024):
After two hours it should start syncing again.
@andbenn commented on GitHub (May 18, 2024):
I have three different computers with Brave, each has a tab profile with 5.1.2. 2 of the three tab profiles have been locked for more than 2 hours. The lock file times are 13:57 and 14:25, and it's now 18:10.
They are configured to send diagnostics back.
Both say they are scheduled. I have Autosync at 15 minutes for both of these profiles. And just as I'm writing this, both tab profiles indicate they sync'd and now have the green check mark.
Looking at my webdav storage, the .lock files are still present. The profile files have a near current time, but the lock files have those times 6-7 hours back. Let me know if you need anything.
@andbenn commented on GitHub (May 18, 2024):
Additional bizarreness. Now the two Braves on their unique tab profiles are scheduled and lock pending.
The profile files times hasn't changed since my last post. Nor the lock files. Seems like it forced a sync, then got into it's loop due to the lock file. is it supposed to do that? i thought the lock file would get removed after 2 hours.
@marcelklehr commented on GitHub (May 18, 2024):
I would need a log from a sync run that didn't remove the lock.
@marcelklehr commented on GitHub (May 18, 2024):
The common theme seems to be that it fails to remove the lock files on brave
@andbenn commented on GitHub (May 18, 2024):
You may be correct. The other Brave I have is my work laptop, a Mac. It's Autosync'd for every 10 minutes. I'm constantly opening/closing tabs all day. Both it's tab profile and bookmark profile are green, up to date. But it hasn't sync'd in 4 days.
Clicking the sync button does nothing. I'll review it tomorrow due to the current late hour. Thank you!
@marcelklehr commented on GitHub (May 18, 2024):
You may need to force an update there, because of the initially faulty build in v5.1.2
@G-Huber commented on GitHub (May 18, 2024):
I am experiencing persisting lock files when syncing tabs with Firefox on Manjaro Linux. Server side is lighttpd providing webdav.
I tried to get a log that shows this, but wasn't yet able to identify an instance of this in the logs.
Got a few thoughts on the issue though:
Unlike bookmarks tabs are fast changing. Opening and closing 3-5 tabs within one minute is absolutely possible. Maybe sync attempts in quick succession are interfering with each other?
Also unlike bookmarks closing a tab and then closing the browser is a rather usual thing to do. Maybe sync attempts don't complete? (This can't be the only reason for this behaviour though - i've seen persisting lock files even when all browsers remained open.)
I've also taken a look at the lockfiles themselves and would suggest an improvement:
Put a client (or profile) identifier in there. Currently even the client that originally created that lock and therefore holds it can't release it if the mechanism got stuck. Even setups with only a single client could theoretically lock themselves out from syncing.
With an identifier attached that client would be able to know that the lock is held by itself and it's okay to proceed with their operation and finally release the lock.
This way there is at least a chance for syncing to get unstuck.
@marcelklehr commented on GitHub (May 18, 2024):
Yeah, I had the same idea :)
@G-Huber commented on GitHub (May 18, 2024):
Additional strangeness: Logs (gotten via Floccus log download functionality) only ever contain a single line:
Log from 2 minutes ago:
2024-05-18T11:16:04.483Z Resource is locked, trying again soonLog from 1 minute ago:
2024-05-18T11:17:05.428Z Resource is locked, trying again soonThat's it. Those are the complete logs. Overwritten each time, it seems.
@marcelklehr commented on GitHub (May 18, 2024):
Mh, if the logs are unreliable then you can debug via the inspector console:
chrome://extensionsDeveloper modeService workerbutton in floccus' entry next to "Inspect views: " to open the console@G-Huber commented on GitHub (May 18, 2024):
Even more strangeness:
The last modified date on the lock kept changing. (I made sure only one of my clients is currently up and running. Everywhere else I closed FF.)
lighttpd access.logs tell me that the client actually DOES permanently recreate that lock.
This keeps going. There are constant PUT requests on that lock which return HTTP 201. All the while the client thinks it can't acquire the lock.
Edit: Oops. Seems I confused two different locks here. Sorry!
Edit2: No, I did not. Bit more log (only the parts regarding the stuck lock)
@marcelklehr commented on GitHub (May 18, 2024):
Aha! That's likely the interval timer that re-sets the lock during sync, but it should be cleared upon ending the sync run.
@marcelklehr commented on GitHub (May 18, 2024):
I think I can reproduce this when syncing using "pull down"
@marcelklehr commented on GitHub (May 19, 2024):
I was hoping v5.1.3 would fix this but it doesn't seem to have done that. Can you confirm?
@marcelklehr commented on GitHub (May 19, 2024):
@G-Huber Can you try to debug via the inspector console (see above)
@G-Huber commented on GitHub (May 19, 2024):
I updated two of my clients this morning and let them run AFK all day with a 15 minute sync interval on tabs. At first it looked promising - yesterday I basically got this issue immediately.
Upon returning I found a stuck lock - which somehow got unstuck just now:
All I did was start the Android client on my phone.
Server logs:
It looks like one of the two clients somehow tries to do everything twice...
I'm on Firefox as I mentioned. I tried to find the equivalent there but haven't been successful...
In the extension storage there is a logs array - but with a stuck lock this only contains a single entry - same as the logs I provided above.
If you could point me to the right place I'll check once there is another stuck lock.
@marcelklehr commented on GitHub (May 19, 2024):
Right.
Firefox
about:debuggingThis firefoxdebugbutton next to floccus entry to open the console@G-Huber commented on GitHub (May 19, 2024):
I think I managed to catch a lock getting stuck:
Server
Client
Firefox addon debug console is flooded with two types of messages:
If I filter down to "log" nothing is left.
@marcelklehr commented on GitHub (May 19, 2024):
Nice catch! and this client is also on v5.1.3?
@G-Huber commented on GitHub (May 19, 2024):
Yes. All logs provided show clients with V5.1.3 - except the Android App which is 5.1.2 but shouldn't really matter here anyways.
@marcelklehr commented on GitHub (May 19, 2024):
Damn, so my fix in v5.1.3 really didn't work. Can you try these builds here?
floccus-build-v5.1.4-alpha.1-firefox.zip
floccus-build-v5.1.4-alpha.1-chrome.zip
How to install alpha/beta versions
Chrome (separate testing installation)
chrome://extensions/Load unpacked extensionand select the folder you createdChrome (direct upgrade; might not always work)
chrome://extensions/.crxfile into the page to installFirefox (separate testing installation; cannot upgrade)
about:debuggingLoad tempoprary addonand select the manifest file in the folder you created@andbenn commented on GitHub (May 20, 2024):
Floccus backing up bookmarks? I don't see that in 5.1.3. I do take browser bookmark backups weekly, so I'm relatively safe on that front.
I'm still seeing Tab profiles getting .lock files from Brave and Chrome (each go to an unique profile). My bookmarks has a .lock but my browsers seem to be running right over it. Timestamp on the bookmark .lock shared with all my browsers is yesterday; the actual file within the past hour.
@marcelklehr commented on GitHub (May 20, 2024):
Sorry, that comment belonged to another issue :D
@marcelklehr commented on GitHub (May 20, 2024):
Ah, that's a new issue due to my fix 🙈 I'm building a new alpha version, it would be great if you could test it.
@marcelklehr commented on GitHub (May 20, 2024):
Can you try these builds, please? 🙏
floccus-build-v5.1.4-alpha.2-firefox.zip
floccus-build-v5.1.4-alpha.2-chrome.zip
How to install alpha/beta versions
Chrome (separate testing installation)
chrome://extensions/Load unpacked extensionand select the folder you createdChrome (direct upgrade; might not always work)
chrome://extensions/.crxfile into the page to installFirefox (separate testing installation; cannot upgrade)
about:debuggingLoad tempoprary addonand select the manifest file in the folder you created@G-Huber commented on GitHub (May 20, 2024):
I've been running my two clients on 5.1.4-alpha for the last ~12 hours.
lighttpd logs don't show a single entry where a GET was performed on a lock and answered with HTTP 200.
I'd interpret this as no lock getting stuck this time around. (For yesterday there are plenty of GET locks answered HTTP 200 by the server because a lock file already existed.)
I'll keep monitoring this throughout the week, but I won't be able keep both clients up all the time.
@marcelklehr commented on GitHub (May 20, 2024):
Awesome, that is alpha.2 I hope? :)
@andbenn commented on GitHub (May 21, 2024):
I may try the alpha 5.1.4-2 build soon. Still on 5.1.3. But I've got a different problem with my tab profile. This is the second time this situation happened.
I've got a Brave tab profile unique to one browser. I've got many browsers open, and each browser has many tabs. Maybe 10 browsers, say 7 tabs average. My autosync interval is 15 mins. WebDav to fastmail.
I rebooted my Mac and things looked ok. Stepped away and came back to the fan going. Seems that the extension pulls the tab profile, and starts everything. And hits a loop. I have now probably about 90+ windows with 7 tabs in each, and a mac that sounds like it's going to take off. And is not usable. There are series of several browsers repeating over and over. The previous case had a window that 4 tabs kept getting added to, over and over and over and over.
Rule of thumb: before rebooting or restarting one's browser, they may want to ensure the tab profile is good and syncing normally. I think floccus was in "schedule" zone.
I managed to disable the extension which should stop additional windows from opening while my system tries to catch up.
Edit:
More I think about this and see my Mac... could there be floccus collisions on windows that are different but have the same first tab? Say 3 windows open, and the first tab are all blanks. They'll be "New Tab", or two or more tabs with teh same name ?
@marcelklehr commented on GitHub (May 21, 2024):
Yeah, I generally discourage people from using auto-sync with tabs profiles unless it's just to push changes.
@andbenn commented on GitHub (May 21, 2024):
I will do that soon. I did edit my comment (and forgot to save it) about potential tab name collisions causing issues. And as the window name (in chromium browsers)
@marcelklehr commented on GitHub (May 21, 2024):
I'm closing this for now, as v5.1.4 is released now, please shout if this does happen again!
@github-actions[bot] commented on GitHub (May 22, 2025):
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.