I am thinking about creating a directory like ~/phone_favorite_hardlinks on my Linux server. It will contain hard links to individual files deep in the directory structure that I want to sync to my Android phone for editing there.
Any reason not to do that?
Syncthing (like most other things) doesn’t do in-place writes to existing files, so your hard links won’t remain hard links when the changes come back.
Does this mean the inode changes for every write?
Every time a file is synced / replaced, yes.
Consider reversing the setup – moving those files to ~ phone_favorite_hardlinks, then soft linking to them in their original locations. Syncthing, rsync and other tools can then sync them without needing to know the symlinks exist.
But soft linking always requires syncing the targets too. Say I have:
data/some/path/foo → phone_favorite_hardlinks/foo
Then, if I use Syncthing to sync data to another machine, I need to sync phone_favorite_hardlinks. However, phone_favorite_hardlinks is interesting only for the phone.
Anyhow, I am thinking about implementing a more robust solution which utilizes my personal system for identifying and linking files. I note it down below, which is more for my own reference:
Many of my text files – and those are the ones that I want to favorite – contain a line near the end to give them an ID in the form of a URL. For example ~/Syncthing/my_data/software/tools/Syncthing/ has:
DocURL: http://f76.eu/aW7
Using a Systemd timer, my server regularly creates an index. It gets stored in a file docurl_cache, which gets synced to my desktop machine. Example content:
[…]
aW7 software/tools/Syncthing/README
aW8 software/tools/Syncthing/forum/README
aW9 software/operating_systems/Linux/systemd/README
[…]
This file is used to resolve the URLs internally inside my VPN. I also wrote a couple of Lisp functions that I use to quickly jump from one file to another in Emacs.
Now, I could actually use this system to set up favorites:
Create a file favorites.conf. It contains the above IDs with custom file names. Taking some of the entries from above, I might create:
aW7 Syncthing_notes
aW9 info_about_Systemd
From the same Systemd timer as above, I could run rsync to sync files:
~/Syncthing/favorites/Syncthing_notes ⇆ ~/Syncthing/my_data/software/tools/Syncthing/README
~/Syncthing/favorites/info_about_Systemd ⇆ ~/Syncthing/my_data/software/operating_systems/Linux/systemd/README
~/Syncthing/favorites can be synced to my phone using Syncthing. No hard- or softlinks are involved.
I MY opinion your are making this overly complicated.
I have a “dokuments” directory which I share between all devices, including phones. I only keep documents there so it is a few gigabytes, but not huge. So it is small enough to share with all devices.
Then I also have other directories which are huge, like the entire photo directory. It is also shared by the NAS. Devices with smaller storage only sync the last couple of years worth of photos by using “.stignore”.
I think the concept of using links inside a single shared folder pointing outside seems very dangerous.
where is the folder marker?
What happens if a link fails to mount?
What does syncthing do when it sees the marker is present but the folder is gone?
poof?
Yeah this isn’t worth it. There are perhaps other ways to achieve what you want but I would make sure you fully understand the mechanism before going all in.
Well, the above scenario is outside the scope of the original question. 
Although the directory phone_favorite_hardlinks happens to include the word “phone”, it’s also of interest to data even though it sits outside the data subdirectory.
Sounds like it could work, but complexity almost always leads to unexpected complications.
Given the updated requirements, a much simpler, cleaner, and more reliable solution is to set up a Syncthing folder that syncs `~/data’ to your Android phone.
Then, using Syncthing’s ignoring files feature, add patterns that include only the target files to be available for editing on the phone – e.g.:
!/some/path/foo/bar/notes.txt
!/some/path/foo/bar/bar/notes.txt
!/some/path/foo/bar/foo/bar/notes.txt
*
A bonus is that unlike ~/phone_favorite_hardlinks which requires unique naming of hard/soft links, you can have as many files as you wish share the same name because the source directory tree is replicated.
For your other machines, add a second Syncthing folder that syncs ~/data with no ignore file, or a different set of ignore patterns.
Alternatively, if you’d prefer to use a single Syncthing folder, sync ~/data to all devices. On the phone, add ignore patterns so that the phone only pulls the files it’s interested in.
The advantage would be a flat hierarchy, which I prefer for these favorites, and safety: There is no way to even sync everything in case someone gets access to my phone. Complexity may lurk somewhere there, but it’s probably just a few lines of Perl.
I still might consider this, though, for simplicity. I didn’t think about the inverse ignore pattern. Thanks for reminding me!
For safety, the dual Syncthing folder approach would give your Linux server control via (inverse) ignore patterns over what’s sent to your phone while also allowing you to sync it all to other machines.
But trying to simultaneously maintain a nested directory tree on one side that’s connected to a flat hierarchy on the other isn’t practical on most systems. It’s a classic conundrum… security, flat hierarchy, bidirectional sync – pick any two.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.