Folder markers are now directories (v0.14.38)


Beside that, the nice side is we now have homogeneous .stfolder & .stversions side by side


If we move versions and ignores into the .stfolder directory, there will be only one folder, instead of one folder and some files. --> better than before :wink:

(Audrius Butkevicius) #23

Thats another thing that could move into stfolder.

(deroby) #24

Like already mentioned above, plenty of “similar” programs create a hidden directory in the root-folder to store information in. E.g. SubVersion creates a “.svn” folder that holds lots of repository-information regarding the branch you’ve checked out locally.

In a way it would make sense if ST would store ALL information regarding the shared folder in said directory. Currently my %appdata% folder contains a 5Gb Syncthing/index-v01.14.0.db folder. Unless ST is capable of ‘copying blocks’ across different shares I’d think having said db split out per shared folder should be easier to maintain.

Then again, my %appdata% sits on a (small) SSD making db-access much faster than on the external(!) HDD … in fact, moving the meta-data to the same location as the data probably will cause some extra disk-trashing… But when my SSD overflows I’m in even more trouble! Aarrgg, why isn’t there ever an answer that solves all situations =))

(Antony Male) #25

It is capable. This would not work.

(Jakob Borg) #26

There’s multiple trade offs involved here. Read only folders, folders with very little free space, folders on SMB or NFS, folders that are also synced in parallel with other tools, and so on. There are also performance aspects of having n databases open and in sync rather than just one. All in all it would often be impractical to keep the database in the folder.

(Ben Curthoys) #27

It broke a script for me… I had a folder of “Builds” and each subfolder was a version number, so I had to update the powershell to exclude .stfolder otherwise it threw a wobbly when it tried to cast the folder name to a system.version.

if ($targetVersion -eq "Latest")
    $version = Get-ChildItem $buildPath | Where {$_.psIsContainer -eq $true -and -not($_.Name -eq '.stfolder')} | %{[System.Version][String]$_} | Sort-Object -descending | Select-Object -first 1;	

Not a big deal but it came as an unwelcome surprise.

(Mike O) #28

Any chance syncthing could set the folder to hidden on a windows filesystem, even when syncthing runs on linux and the windows fs is only mounted?

My setup: Windows host; Linux virtual client; Syncthing running on Linux; Syncing files on the D drive, mounted as /media/sf_D_DRIVE/

Explaining the reason for all that would take to long, but I am heavily interacting between Linux and Windows.

For now I have set the hidden attribute manually. Hope that does not break anything.

Besides that, a big thanks again! I have almost forgotten that I run and rely on syncthing. It just works, silently.

P.S. the [x] ignore permissions on FAT FS is set, so that could be used as indicator

(evert) #29

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.

(Ben Curthoys) #30

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) 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.

(Jakob Borg) #31

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.

(John Veness) #33

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.

(Wolf) #34

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?

(Audrius Butkevicius) #35

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.

(Wolf) #36

AH. Right. Damn. Thanks!

(Brian) #38

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.

(kisolre) #39

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.

(Audrius Butkevicius) #40

There is nothing yet, but it might change in the future.

(Paul) #41

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.