[GH-ISSUE #490] Export and auto import from a local file (sync via NC client) #356

Closed
opened 2026-02-25 22:36:55 +03:00 by kerem · 8 comments
Owner

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.

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.
kerem 2026-02-25 22:36:55 +03:00
Author
Owner

@marcelklehr commented on GitHub (Apr 10, 2020):

Hello @dsiminiuk 👋

Syncing to the NextCloud bookmarks plugin takes a minute or longer to sync. Yes, I have a lot of bookmarks.

I am aware of the performance problems with the bookmarks app. We're working on it and have seen some good results already.

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.

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.

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.

Theoretically that is a good idea, however browser extensions do not have access to local files.

<!-- gh-comment-id:612033716 --> @marcelklehr commented on GitHub (Apr 10, 2020): Hello @dsiminiuk :wave: > Syncing to the NextCloud bookmarks plugin takes a minute or longer to sync. Yes, I have a lot of bookmarks. I am aware of the performance problems with the bookmarks app. We're working on it and have seen some good results already. > 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. 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. > 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. Theoretically that is a good idea, however browser extensions do not have access to local files.
Author
Owner

@dsiminiuk commented on GitHub (Apr 10, 2020):

We're working on it and have seen some good results already.

That's good news, I'll give it another try when ready.

Do you know by any chance, when those lingering lock files usually happen?

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.

however browser extensions do not have access to local files.

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.

<!-- gh-comment-id:612039612 --> @dsiminiuk commented on GitHub (Apr 10, 2020): > We're working on it and have seen some good results already. That's good news, I'll give it another try when ready. > Do you know by any chance, when those lingering lock files usually happen? 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. > however browser extensions do not have access to local files. 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.
Author
Owner

@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.

<!-- gh-comment-id:612042487 --> @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.
Author
Owner

@marcelklehr commented on GitHub (Apr 10, 2020):

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.

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 :)

<!-- gh-comment-id:612048736 --> @marcelklehr commented on GitHub (Apr 10, 2020): > 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. 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 :)
Author
Owner

@dsiminiuk commented on GitHub (Apr 10, 2020):

then that's a separate problem that I'd like to hear about :)

More to come, next time it happens.

<!-- gh-comment-id:612052634 --> @dsiminiuk commented on GitHub (Apr 10, 2020): > then that's a separate problem that I'd like to hear about :) More to come, next time it happens.
Author
Owner

@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?

<!-- gh-comment-id:612636835 --> @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?
Author
Owner

@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.

<!-- gh-comment-id:612650056 --> @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.
Author
Owner

@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.

<!-- gh-comment-id:1477257030 --> @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.
Sign in to join this conversation.
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#356
No description provided.