No please no different folder names across operating systems. I’m dual-booting and planning to use the same data partition for a Windows and a Linux instance. I’m using Syncthing for both at the moment.
2 Likes
Oh, and, where I’m running syncthing as a Windows service with limited permissions (as recommended), I get
[W5AVU] 07:28:50 INFO: syncthing v0.14.38 "Dysprosium Dragonfly" (go1.9 windows-amd64) teamcity@build.syncthing.net 2017-09-07 09:40:46 UTC
[W5AVU] 07:28:50 INFO: My ID: <redacted>
[W5AVU] 07:28:51 INFO: Single thread SHA256 performance is 109 MB/s using minio/sha256-simd (79 MB/s using crypto/sha256).
[W5AVU] 07:28:51 FATAL: failed to upgrade folder marker: remove \\?\D:\Builds\.stfolder: Access is denied.
Not a big deal but annoying and surprising.
That’s a misfeature; the failure to change the marker type should not be a fatal error. We’ll fix that for the next release.
I think it is a good idea to use a directory instead to avoid the multiplication of files, it is better if all syncthing config files are in the same directory rather than polluting the folder to be sync. Don’t bother making name differences between linux and windows it is likely to create issues for very limited cosmetic interest.
1 Like
This change surprised me too, and I sympathise with people who find is aesthetically unpleasing. However, I guess we’ll get used to it. I agree you should keep the same folder name on all systems.
The only thing I would add is to mention this kind of change in a changelog, or even better, announce it in advance so people aren’t too surprised when it happens.
2 Likes
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:
#include .stfolder/.stigore
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.
AH. Right. Damn. Thanks!
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 .stfolder but bladibla.docx. Then bladibla.docx must exist or syncthing will stop.
1 Like
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.
1 Like
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?