I synchronize some text files (todo.txt style of note-keeping). One of these files I use as a clipboard, to share temporary data between devices. I usually open the file, copy its contents to my clipboard (do something with it), then finally wipe its data. I have been doing this for a long time, and it never failed me…
Sadly, I lost the contents of this file today. Here’s how it happened:
From my Android phone, I added some lines to clipboard.txt (meanwhile my desktop was powered off).
I turned on my Linux desktop computer, quickly opened that file, copied its contents to my clipboard, and finally erased everything in it.
Well, it turns out that the file I had just opened on my computer was not yet synchronized to the file I wrote earlier on my phone. Syncthing did not pull in the latest changes, but it was quick to propagate the local deletion of the file’s content to all devices.
These are the changes that the desktop (hostname helium) picked up:
As you can see, the timestamps don’t match. On the desktop there’s a huge time gap between 14:45:02 and 17:45:59. Only the Android app is reporting the correct time of events.
I have automatic backups, but they’re done once a day. All of this happened in, like, 15 minutes.
System info:
My window manager (Sway) starts Syncthing when I log in.
Desktop version: v1.27.12, Linux (64-bit Intel/AMD)
I happen to have a very similar setup and workflow, except I also use i3 and GNOME desktop environments.
I also use Markor to take notes and have one text file that acts like a shared clipboard between my phones, tablets and PCs. However the big difference is that I only overwrite my clipboard file instead of deleting it.
I’m not sure of the usefulness of deleting the clipboard file after copying the contents to the local clipboard because an unexpected power outage, hardware problem, and/or some other issue could result in losing the clipboard buffer.
So based on your description of events, it sounds like Syncthing did exactly what it was designed to do (continuous bidirectional file syncing).
Was there a question or request for help on anything in particular?
In that case, because a file was modified on two different devices, there should have been a conflict file with one version of clipboard.txt renamed to the pattern clipboard.sync-conflict-<date>-<time>-<modifiedBy>.txt.
Yes, in general it’s best to allow enough time for the bidirectional sync to finish to avoid issues.
For my setup, I changed the default pull order from random to newest first so that my “clipboard” file (which is most frequently updated) gets synced first to reduce the chance of conflicts.
Sadly, I didn’t get any conflict files on neither sides.
Thanks for the suggestion, I will look into that option. You do that in the folder config, right?
Probably unrelated to my issue, but what re-scan interval are you using? Mine is currently 30 minutes, but I wonder if it’s a good idea to decrease it even more.
What text editor do you use to wipe the contents of your clipboard file while on your desktop?
Yup, for the selected folder, click Edit → Advanced → File Pull Order.
Although I have SSDs in every device, my full rescan interval is 3600 secs (1 hr) because Syncthing’s file watcher on my PCs and Android (both are using the inotify subsystem in Linux) catch most (if not all) of the updates.
Yes, that, and also wondering if the editing program played a part in there not being a Syncthing conflict file.
98% of the time when I’m editing a text file on a Linux system it’s with vim, 1% it’s sed -i – yes, I’m a , and the remaining 1% it’s a hodgepodge of editors.
Because I don’t care about syncing Vim’s swap/scratch file that it temporarily uses instead of the original text file, I have a *.swp ignore pattern configured in Syncthing.
The downside to ignoring Vim’s swap file is that Syncthing won’t be quietly syncing the swap file (e.g. clipboard.txt.swp) while I’m intermittently saving changes, then efficiently reusing the data blocks to update clipboard.txt when I finally do a :wq.
Short version is that Vim doesn’t edit in-place. It renames its swap file to replace the previous file version (as indicated by the file inode changing).
I used to use Xfce on an older mini laptop, but switched to i3 a while ago so don’t have quick access to Xfce’s mousepad to check things out.
I use multiple computers also and different platforms like Android windows and Linux and often want to copy the contents of the clipboard from one device to another and there is an application that works on every device that handles this very nicely.
It’s called KDE Connect and you put it on your phone and on your computer and you can send the contents of your clipboard from your phone to your Linux computer and back using this app.
, and the remaining 1% it’s a hodgepodge of editors.