I am new to Syncthing. I am attempting to sync my Chromium web browser profile from one computer to another. This appears to work well, except for one small glitch:
I open Chromium on computer A. Then close it. I go over to computer B and attempt to open Chromium. It thinks for a few seconds, then exits. I have not yet looked through logs to see if there is any info about the premature exit/crash. Then I immediately try to start up Chromium again on computer B and it works perfectly, starting up immediately with no delays. Any changes I had made on previous computer A appear to be successfully synced to current computer B. The exact same behavior occurs if I now go back over to computer A. The first attempt to start Chromium dies, but the second attempt works perfectly.
Is this a normal occurrence with Syncthing and browser profiles? I was not expecting this. But it’s a minor issue that I think I can live with (maybe).
Both computers are near-identical software-wise. Both are Linux and run LinuxMint. One runs version 21.3 and the other runs version 21.1. The versions of Chromium on the two computers are identical. The versions of Syncthing are identical too. One computer is a self-built desktop, the other is a Dell Latitude 5411 laptop.
Note that I have been careful to close Chromium on one computer and waiting for about 10 to 15 seconds before trying to open it on the other computer, to allow Syncthing to do its thing. Is this a long enough time for me to wait? Since I did nothing but bring up Chromium and maybe add one bookmark, there shouldn’t be much data to sync.
One other thing after moving between computer A and computer B … I did notice that I had been logged out of websites that I am normally permanently logged into (via cookies or whatever they use to remember login state). I imagine this may be more of a Chromium gotcha than a Syncthing gotcha.
I’m starting the think that syncing a browser profile might not be such a great idea. I have been careful to not have the browser open at the same time on both computers in the sync partnership. So where are the conflicts illustrated below coming from? My browser profile directory is starting to get polluted with Syncthing files. Is it better to only sync items that are smaller and more static in nature?
I’ll probably let this go for another day or two and see how bad it gets. Then if I decide to quit syncing Chromium I can just restore my profile from a backup prior to Syncthing. I wouldn’t lose anything of consequence - maybe the random bookmark here and there, but nothing Earth shattering.
The default watcher delay (until detected changes are propagated to other devices) is 10 seconds, but can be lowered. And the actual synchronization takes some time, too. So with your 10 seconds waiting you’re living on the edge.
In general I wouldn’t think syncing browser profiles is a good idea. Don’t know exactly about Chromium, but for Firefox at least, some sqlite databases are involved. Those are usually opened by memory mapping, which does not reliably trigger the file system watcher on changes. And even the regularly scheduled scan requires some metadata change to consider re-hashing the file, which might not happen depending on how the browser handles the files.
I’ve been syncing Chromium profiles for years now. I’d say the key is to work out what actually needs syncing and what can be safely ignored. There are a lot of log and cache files inside the profile folders, which are completely unnecessary to sync, and doing so will only slow down the overall synchronisation. You also do need to make sure that everything has finished syncing before opening the browser on another device.
For example, these are some of my ignore patterns related specifically to Chromium:
Thanks for the help @acolomb and @tomasz86. I appreciate this forum for the help people give. I am learning Syncthing, but it sure is a lot faster (and easier) to build my learning on top of the learning others have already done and are willing to share.
I was starting to come to the same conclusion that you have made - that syncing ALL of a Chromium (or any browser’s) profile is a bad idea. For one, you don’t need 95% of all that stuff. Bookmarks are a good thing to sync. Website passwords are a good thing to sync. I can’t think of much else that is really needed. Cookies would be a desirable thing to sync, but there are inherent problems in that (probably why I am logged out of all my “remembered” websites after a sync). Cookies are probably created using data that is unique to a given computer, so when synced to a different computer they’re just not going to work (my guess). Passwords might fall into a similar problem, not because of computer uniqueness, but because they might live in a database. Syncing/backing up a running database is not trivial (not the large ones I dealt with at work). I can see potential problems with database corruption when using Syncthing without thought.
In normal times, I won’t have to worry about how long I should wait before using one computer after abandoning the previous one and triggering a sync. That will be measured in hours, if not days or longer. It’s just now, during testing, that I have both my desktop and my laptop sitting right here in front of me, both active.
I realize that I could corrupt my stuff during my rapid fire testing of Syncthing. This doesn’t bother me - I have solid, automated daily backups for all my computers that go back for a year (except for the laptop, which is new (to me) and I’m just building it up now).
I’ve been using a combination of remote mounts from a central server (NFS and samba), a self-hosted Nextcloud instance, automated backups (that are accessible from any computer), sshfs, etc. to handle my “sharing” in the past. I figured it’s long past time that I should learn Syncthing. All these different ways of sharing/syncing complement each other, they don’t compete (well I guess they can, if you don’t know what you’re doing). I just had put off learning Syncthing, … no reason other than being lazy. The recent addition of a new laptop triggered me into learning Syncthing finally.
For me it’s mainly about the browser and extensions’ settings. I’ve got everything heavily customised, including feature flags and plenty of extensions, so having to maintain all that on each device separately is just unfeasible, especially if I decide to make some changes and want to have them reflected everywhere.
Can you tell me how the above two ignore lines interact?
The second line would normally tell Syncthing to sync everything under “default”, correct? We don’t want that. So the line above, the “(?d)” line, must modify the behavior of the second line or modify what’s left to sync before the “!(?i)” line comes into play. I know the docs say that the “(?d)” line “enables removal of these files if they are preventing directory deletion”.
My brain synapses must not be firing this morning because I’m not putting together how these two ignore lines work in tandem. Can you explain the intent/effect of this two ignore line combination to me? (Maybe I’ll figure it out on my own after I have a cup of coffee and wake up!)
These are basically some gymnastics to work around https://github.com/syncthing/syncthing/issues/8735 (also check my last post there). Ideally you would only need (?d)(?i)<path-to-chromium-data>/, but because of what happens as described in the linked issue, I want to ignore everything inside (?d)(?i)<path-to-chromium-data>/{default,profile *}/ first, then unignore just the parent folders with !(?i)<path-to-chromium-data>/{default,profile *}, and only then ignore everything inside (?d)(?i)<path-to-chromium-data>/, hence the whole sequence:
Ah, OK! Bug/quirk/anomaly/design workaround. I guess my brain synapses were kindof firing OK this morning. It really is not immediately apparent what you were doing there, it wasn’t just me (or at least I hope not!) Your additional context and the link to the Github thread explained it. Thank you.
It’s the latter. I don’t even save passwords in the browser, so I don’t need to sync the file. I also don’t want to sync cookies, so the related file isn’t included either.
Agreed. The only cookies I might care about are the ones that keep me logged into websites. But those didn’t work anyway when synced per my testing, so no need to sync any cookies at all IMHO.
Passwords - I don’t store any passwords to important things in the browser. I have a separate password manage for that (KeePassXC in my case). I do store passwords for some less important things, like my login credentials for this Syncthing forum for example. “Less important” is not the right way to say that. What I mean is “If this password gets out into the wild, I won’t really care too much about that. I’ll just go change it on the website if needed.”
Below is my initial attempt at the /home/username/.config/chromium/.stignore file. I will begin testing this soon, maybe not until tomorrow though. I broke up your long line into shorter ones organized into groups of related function (or at least I think they are related or logical groups, as best I can guess by their names). I also added comments so I might have some clue what I’m reading when I stumble into this file three years from now and ask myself, “What is this gibberish?!”
// Lines below that begin with ! are things that we WANT to sync
// Lines that do not begin with ! are things that we DO NOT want to sync
!(?i)/{first run,local state}
!(?i)/default/{bookmarks,login data,favicons}
!(?i)/default/{preferences,secure preferences}
!(?i)/default/{local storage,web data}
!(?i)/default/{sessions}
!(?i)/default/{extensions,indexeddb/chrome-extension_*}
!(?i)/default/{local extension settings,managed extension settings,sync extension settings}
// WORKAROUND for Syncthing bug #8735 per Github user tomasz1986
// The intent is to sync the directory names, but not their contents
// That happens even without these lines, but they create a cleaner Syncthing console display
(?d)(?i)/default/indexeddb/
!(?i)/default/indexeddb
(?d)(?i)/default/
!(?i)/default
// END OF WORKAROUND for bug #8735
// Ignore anything else not specifically marked for syncing in the above rules
(?d)(?i)/
Please report back if you find any issues as these patterns are purely my own invention after a lot of trials and errors. There exists barely any documentation on what is what in the Chromium user data folder.
Also, you may want to keep an eye on the actual folder structure on the disk as it may sometimes change ever so slightly, as it has already been the case in the past, where I was forced to update the patterns to make them work in newer versions of the browser.
Seems to me if they change the directory structure or the file/directory names we have in the .stignore file - that this would just cause the thing that changed not to sync. We might notice that something didn’t sync and think to ourselves, “Hmmm, wonder why that doesn’t work now when it used to?” But other than that, it’s not the end of the world. Especially when we keep good backups (I know I do, and I’m pretty sure you do as well, just by the knowledge/experience evident in your posts).
Syncing between multiple computers is not a replacement for having backups of each computer. Far from it. Everyone should be backing up what they sync, maybe especially backing up what they sync! The bidirectional syncing concept itself puts things at risk.
.