Hi @maelcum
Not sure why you are listing .stignore and .stfolder, they don’t sync.
I like to sync the ~MicrosoftOffice lock files to reduce the chance of conflicts. If it is on a node when I try to open it I know there is a good chance I am about to create a conflict.
@Cyphase, since the thread is back up the top it might be worth updating your original post.
I don’t think it is worth ignoring the *.part or *.crdownload any more because we should be able to pull some of the blocks from them once the move/rename happens. Probably the same thing for .iCloud*.
Perhaps one one of the core developers could correct me if I am wrong.
> Not sure why you are listing .stignore and .stfolder, they don’t sync. yep, I know. The ignore list is the file I’d consult if in doubt what should sync. the .stignore and .stfolder are there as a reminder for me. Just that.
Thanks for the ping @kluppy, and to everyone else who has commented with suggestions. I’m too tired to do an update at the moment , but I’ll do one the next chance I get. I’m glad to see this post has gotten so many views and comments in the time that I’ve been inactive.
A pattern beginning with #include results in loading patterns from the named file. It is an error for a file to not exist or be included more than once. Note that while this can be used to include patterns from a file in a subdirectory, the patterns themselves are still relative to the folder root. Example: #include more-patterns.txt.
Meaning: if you write in .stignore the line: #include .stglobalignores, it’ll search for a .stglobalignores file in the same place that .stignore resides, and then parse .stglobalignore’s contents as a continuation of .stingnore.
(The point of using extra file in addition to the base .stignore, it that .stignore itself is device specific, that is - it won’t sync to other devices. So people use #include some_file_with_patterns_to_sync to add ingore patterns they like to be synced across several devices.)
Thank you. Your answer makes me understand people are putting .stglobalignores files in the same directories as the base .stignore file. That way, it will propagate changes to all devices. ~That~ type of redundancy is good and necessary.
However, the reason I asked was because that seems redundant in a different way when I share multiple directories on a machine. It would seem that each device needs only one .stgobalignores file if the file for each sync set is the same anyhow. Having identical include files a in the sync root directory for 5 or 10 or however many sync root directories is redundant and a configuration nightmare.
You wrote that syncthing will look for the include files “in the same place that .stignore resides.” Is that mandated by syncthing or is that only because in your example, you named no alternate location?
Is it possible to put a single include file on each device - maybe at the user home level - and have each sync root .stignore file reference it, like “#include /home/user/.stglobalignores” ?
If this can be done, why are people creating a new include file for each sync root? Maybe the documentation could be expanded to address this issue.
If this can’t be done, it would be nice to have so I only have to maintain one include file.
Every share (folder) is independent of other shares, so yes you would need .stignore in every folder
Because of my example. In general included files may reside elsewhere, but you need to point to them relatively to the root of this particular share’s folder.
Documentation specifies that included files should reside in the folder itself, or it subfolders:
Note that while this can be used to include patterns from a file in a subdirectory, the patterns themselves are still relative to the folder root.
So regarding placing it in /home/user/whatever , completely outside the shared folder - I’m not sure about it, but you should give it a try, it may just work.
If the above works, I guess a single ignore template file may be used for many shares. Just sometimes people want to exclude different things from different folder pairs.
If using single location won’t work due to some implementation limitation or access rights, it’s not that big of a deal, you can always copy-paste ignores upon folder creation.
You can specify any path as includes, even outside of the folder root, it just needs to be relative to the folder root. I have a Syncthing folder where I share stuff like keypassx database, configs, … There I put a “.stignore-common”, which I include into every .stignore on any machine. So just one file to maintain to ignore stuff like “*~”, “.DS_Store”, … Then sometimes I add a .stignore-folder to the folder root to ignore stuff that is specific to this folder but not Syncthing instance. Works like a charm.
//---Mac-specific---//
//Mac Comments, Finder Windows Size, Tags, ...
(?d).DS_Store
.DocumentRevisions-V100
//Mac Folder Icons, which will not sync to Windows
(?d)Icon*
.Spotlight-V100
.TemporaryItems
.Trashes
.fseventsd
//Mac Flag to enable translation of Folder Names
(?d).localized
//Mac Temporary iCloud files while synching
.iCloud
//Mac OS Metadata on Windows or Linux filesystems
(?d)._*
//---Windows-Specific---//
(?d)desktop.ini
(?d)Thumbs.db
(?d)$RECYCLE.BIN
//---Linux-specific---//
.Trash-*
//---QNAP-specific---//
(?d).@__thumb
(?d).AppleDB
//---Synology-specific---//
(?d)@eaDir
//---Application-specific---//
//-Syncthing
(?d).stignore
(?d).stfolder
//-vi(m)
(?d)*.*.sw[a-p] # Thankys to Tom Hale!
//-Dropbox
.dropbox
.dropbox.attr
//-Microsoft Office temporary files/lock files
(?d)~*
//-KDE
.directory
//---OTHER---//
Microsoft-Benutzerdaten
Notizbuch von Wolf.url
Outlook-Dateien
RDC Connections
.parallels-vm-directory
Default.rdp
Thanks for this.
For Adobe Lightroom I started getting lots of sync errors concerning the preveiews.db files, so I suggest the following (not perfect and surely can be improved):
Not a good idea because not all “dotted” files/folders are unnecessary. Take for example .htaccess, which is normal in a web development environment and basically mandatory for anything Apache related. Loosing a .htacess file would be huge. There are many other examples as well.