Full ack. And the best way to get over this for me is to make use of it…
Today I have three .st<something> files:
- . stfolder (was a file, now a folder)
- . stglobal (which has exclusions that are valid for all (my) folders)
- . stignore (which links to .stglobal and has additional exclusions specific to the folder it’s in)
and I sync between Unix and Windows and Mac operating systems.
If I move the .stlobal-file to the .stfolder-folder, the .stignore-file needs to be updated to point to the .stglobal file. That could look like:
Would that path designator work on an OS platform like Windows? Or do I need to change the .stignore-entry on Windows to #include .stfolder\.stignore?
I’ve tried both but cannot see an error in either case. That could mean it works. It could also mean, Synching doesn’t care. Has anybody tried this? Or simply more insight into the inner workings of the new .stfolder-thing?
That won’t work I suspect for now as ignore paths are relative to the file location, rather than the root of the folder I think.
I feel for you guys as developers! What a variety of needs and wants!
I need the semaphore behavior of .stfolder to confirm my mount is up and healthy before syncthing starts doing it’s job. If you need another folder to store some stuff, I’m okay with that - I have to already look past dozens of system chaff files and directories. I’m happy whatever reasonable files or folders need to show up to get the job done.
My 2 cents:
If you need a semaphore marker, you could totally eliminate the .stfolder (as a file and as a folder) if there is any other .st-ish-like file or folder present. In other words, if there is an .stversions or .stignore found at any mount, you don’t need to see .stfolder to confirm the mount is healthy; be happy and start syncing.
If you need instead a folder to stash some files, you might as well put a .stfolder folder at the root and all the other related stuff inside that one folder.
Just realised that under android I use both marker types - folder for internal photo folder and file for sd card photos folder which is read only. If there should be something stored in .stfolder folder it would not be possible in the sd cards folder and brake the ability to sync.
There is nothing yet, but it might change in the future.
Hi - I’m a newbie so i hope i don’t say something stupid, but here goes
I shared a directory with some people and they deleted that funny .stfolder thing because it was not a word file…I did not know what it was either.
I read this very long forum, and maybe it has already been said, but can this folder thingy be moved to a program info directory away from the shared folder?
It is confusing for dummies like me, as it looks like a word tmp file error or left over fragment of something, in an otherwise well organized and clean file directory.
As Syncthing becomes more mature, more newbies will use it and it creates a discussion that could be otherwise be avoided.
No you can’t, as this is the only way for us to tell when a directory was unmounted for example, and not assume that everything was deleted.
You can configure syncthing to look for some other file to distinguish that, but this would have to be configured on each and every client. This is available in advanced config section for the folder.
We do hide the .stfolder though, so a non-technical user should never see it.
For now I have changed the view in Windows Explorer to not show “hidden items”
It hides all those transparent looking folders and files created for system reasons ( not just syncthing ) I think that is what Simon is saying, and is the easiest way.
But thanks for the for the suggestion by Audrius, I will peek in the advanced config and try hiding the .stfolder outside the syncfolders.
The file / folder must still be inside the syncfolder, not outside, even if you tell syncthing, that it should be
bladibla.docx must exist or syncthing will stop.
fun fact: some android vendors love to delete empty folders. (huawei for example)
thus… this change broke sync on alot android devices.
empty file > empty folder
Yes, that’s true. I’ve already planned to resolve this on the Android side. This is exotic like other Android stuff so on my opinion isn’t a need to change something upstream.
Anyone having the same issue on Android reading this? I’ve put up a test APK at https://drive.google.com/open?id=1FyPl16VXL6WAjuazSDIBtaN79ZRCTX0o and would appreciate feedback if this works correctly after adding a new folder and running the phone’s file cleanup utility. The workaround adds a dummy text file below the “.stfolder” directory.
That happened in September 2017 though, so I guess most people would have adjusted since, somehow?
I think he meant the changes from huawei and xiaomi who broke it end of 2018.
i’m on a Huawei Mate 10 Pro so… Android 9 sure came with new „features“ one of wich cleans empty directories.
i circumvented this by just placing a empty file inside.
but i doubt 0815 users who got syncthing as recommendation or got help setting it up will be able to figure this out.
why does this folder need to be present for a successful sync anyways?
i doubt syncthing is unable to recreate it on demand
It’s a safety check to prevent data loss. Imagine a drive with a syncthing folder getting silently unmounted or getting unreadable somehow - if syncthing rescans data, it might think that the user has deleted all of his files which would then propagate to other devices - resulting in possible data loss. Therefore the .stfolder is always checked for presence, to ensure that the directory is in fact readable and deletes are actual deletes and not errors.
If the folder is not present, syncthing assumes the folder has experienced an error (drive unmounted or similar) and will therefore stop it.
That’s why syncthing will never attempt to re-create the folder on it’s own (at least not without user interaction), as that would break the purpose of it.
I spent hours during this month trying to figure out that the reason why my phone kept losing sync was this. Thanks for the workaround.
I guess putting a .dontdeleteme file in there automatically wouldn’t hurt seems like this is the best solution to this day.