mirror of
https://github.com/floccusaddon/floccus.git
synced 2026-04-26 06:35:59 +03:00
[GH-ISSUE #490] Export and auto import from a local file (sync via NC client) #356
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#356
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 @dsiminiuk on GitHub (Apr 9, 2020).
Original GitHub issue: https://github.com/floccusaddon/floccus/issues/490
Is your feature request related to a problem? Please describe. Yes
Syncing to the NextCloud bookmarks plugin takes a minute or longer to sync. Yes, I have a lot of bookmarks.
Syncing to the NextCloud WebDav is much faster but I run into lock files that are not cleared properly which requires a cleanup and recovery of the latest version from wherever that browser is.
Describe the solution you'd like
I'd like to see an additional sync target of a local file (bookmarks.xbel) on the local filesystem rather than a webdav server you have to install to use Webdav. I'm already syncing the folder where I save my bookmarks via the nextCloud client, why not use the native client to propagate the file.
If the floccus plugin detects a newer file than the last local export then import it. No lock files required. If you get conflicts then you can deal with that by renaming files rather than deleting them.
@marcelklehr commented on GitHub (Apr 10, 2020):
Hello @dsiminiuk 👋
I am aware of the performance problems with the bookmarks app. We're working on it and have seen some good results already.
That is unfortunate. Usually, just removing the lock file should suffice to resolve the situation, I think. Do you know by any chance, when those lingering lock files usually happen? Off the top of my head I could imagine that closing a browser while sync is happening would cause this, for example. I could implement an automatic clean up mechanism that clears the lock file if the process has been waiting for it for more than X minutes.
Theoretically that is a good idea, however browser extensions do not have access to local files.
@dsiminiuk commented on GitHub (Apr 10, 2020):
That's good news, I'll give it another try when ready.
Not really. I have 4 PCs that share the same bookmark set, all have your plugin, and from time to time I get the red exclamation point indicating a sync problem. So I have to find one of the PCs that hasn't been overwritten yet with a bad bookmark set. Once I find the machine with the complete set I export the bookmarks as a backup to an html file (native browser export), clear the lock file on the NC server and force a sync from scratch and overwrite remote to get the correct file on the NC server, then go to the other PCs and force a sync from scratch and revert local changes. I've set my sync time to 90 minutes so that I don't write the file very often and between those times I sync manually to ensure it finishes cleanly.
That's too bad and of course that's why you have the local webdav server as the solution. I hate adding extra applications but I will give this a try.
@dsiminiuk commented on GitHub (Apr 10, 2020):
If there was a way to put a timestamp or version sequence number in the name of the xbel file and have the local sync clients keep track of the last known version then it could import any newer file if there is no .lock file present (read only). You should only need to create a lock file if you are updating the file contents (write) for bookmark merges or full sync from a client.
At least find a way to keep the last N copies of the file with a timestamp in the destination folder. When a client syncs the bookmarks.xbel, the file is not deleted so it never ends up in the recycle bin. Having one copy of a corrupted file makes it hard but a few previous copies of the file would make things a lot easier to restore the bookmarks if the xbel gets corrupted.
@marcelklehr commented on GitHub (Apr 10, 2020):
This is interesting. What does the error message say? Is there actually corruption going on? Or is it just the failure to clear the lock file? Failure to clear a lock file shouldn't lead to corruption, just to stale state, which should be recoverable once the lock file is removed. If there is corruption, then that's a separate problem that I'd like to hear about :)
@dsiminiuk commented on GitHub (Apr 10, 2020):
More to come, next time it happens.
@dsiminiuk commented on GitHub (Apr 12, 2020):
Still waiting for webdav to fail, which is good I suppose.
In the new 4.1.0 changelog
NEW: NextcloudFolders: Speedup
Is this a significant fix that I might try that again?
How do I update the plugin from 4.0.4?
@dsiminiuk commented on GitHub (Apr 12, 2020):
OK OK, I uninstalled and reinstalled to get the new version.
The Nextcloud Bookmarks option updates pretty quickly (about 3 seconds) once it gets going, but it took 3 and a half minutes to begin any activity on the bar graph (initial sync).
Subsequent syncs took about 13 seconds. Much better than the previous version.
I will stay with this method for now and see how it goes.
@github-actions[bot] commented on GitHub (Mar 21, 2023):
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.