Is it possible to delete .stfolder and stignore file?

I like to store metadata outside of a disk itself.
Tree of data is well structured and each name makes sense.
And .stfoder is not hidden of course (on Windows and Linux hidden files are not an option for me).

Any chance to get the desired result?

I can understand that work files are disruptive at the root level. It has already been discussed, but surely it will come in the next versions.

You cannot do anything about .stignore (other than not using ignore patterns, that is). When it comes to .stfolder, please read

There is also a known “hack”, where you set the folder marker to ., which essentially equals having no marker. This can be very risky though, e.g. if a drive, where the folder is stored, gets disconnected or something, Syncthing will consider everything deleted and push the deletions to other devices.

A safer approach could also be to set the folder marker to .stignore. This way you could at least reduce the number of Syncthing-related files to one instead of two.

other than not using ignore patterns, that is

OK, but what will Syncthing do with such not accessible directory as System Volume Information? If nothing then I think I can delete lost+found and disable ignore list then ))

There is also a known “hack”, where you set the folder marker to ., which essentially equals having no marker.

Sounds promising.

if a drive, where the folder is stored, gets disconnected or something, Syncthing will consider everything deleted and push the deletions to other devices.

OK, I think it makes sense if device is unmounted. But what if specific path not available at all? In Windows it can be disk itself, so for example there will not be E:\ anymore. On Linux /some/path/share will be just /some if disk is unmounted, so /some/path will not be accessible. It should signal about error during accessing file(s).

Does that not solve the problem?

I have to admit I did not understand the original thread ))
If it means to store all “config” files in .syncthing directory of current user home then it will be very good and I like that idea.
Hopefully it will be released not in years…

It will keep complaining about them, but other than that, the synchronisation itself should work fine for the rest of your files.

Frankly speaking, I don’t know. This is probably untested territory. I would suggest doing some testing yourself with a temporary path, and see what happens then :wink:.


I’ve just tested this. Syncthing does stop with an error if the whole path becomes unavailable. Does this mean that using . as the folder marker is safer than originally thought?

I guess that .stfolder still provides more security, e.g. if you set the sync path to E:\ and then a different drive gets connected using the same letter, Syncthing will check for .stfolder and stop if it’s missing. Such a check will not happen when using ..

Maybe I did not interpret your contribution extensively at first. As already described, nothing works without the .stfolder, as this file is a functional control file. If this is missing, the sync does not work.

Frankly, it bothers me to this day that all work files are managed in the folder’s root directory. If all the relevant files were in a subdirectory, that would be tidy. In addition, discussions would be superfluous as to which files, which are potentially from third-party programs, belong to Syncthing or not to Syncthing. You can read about it here again and again.

That’s a bug, don’t do that. It will be fixed soon:

1 Like

As I mentioned in the pull request, I personally hope not, because this will break syncing for those that are forced to operate on locked read-only folders with no static files that could be used as the folder marker. Folder markers outside of the folder are another story though :wink:.

I’ve read about this hack originally in an old forum thread from a few years ago (if I remember correctly; cannot find the thread though), so there must be at least some people actually using . for quite a while now. Disabling it suddenly like that will likely break Syncthing for them.

Ok I get it, there may be valid-ish circumstances to use that. However “I don’t like .stfolder in my Syncthing root path” is not a good use-case - please stop recommending it unless it’s very clear the user has a good grasp of their setup and Syncthing and this hack really is the only way to go.

1 Like

I don’t really think I recommended the option. It was more like a description of a technically possible solution, and with a warning right next to it. The user is aware of the risks, and if they still pursue this route, it will be their conscious decision, whatever their reason may be.

In this case, they specifically asked whether they could disable stfolder. Telling them that “it is impossible” would be just deceiving them, in my opinion.

I will stay silent next time if this it the preferred solution to this problem.

That’s not what I wanted. I am just worried about making a hack more broadly known which may then lead to people implementing it without thinking, and eventually complaining about “Syncthing ate all my data”. And of course they won’t say "Syncthing ate all my data after I changed the folder marker to .). You indeed accompanied it nicely with a warning about data loss, that’s nice done :slight_smile:

1 Like

Understood :innocent:. I will keep this mind.

I myself just use the defaults, but I personally know people who absolutely hate any superfluous files or folders being created automatically and then sitting there. In one case, I specifically had to set some scheduled scripts that hide unfinished Syncthing tmp files and similar stuff, or otherwise they would keep bothering them :neutral_face:, so I kind of understand the situation here.

Same in my case. Therefore is better to have a “Syncthing” subfolder to have a focused control and to have in the root level all the normal and daily work files.

Instead of Syncthing using an .stfolder marker to identify a folder under it’s care, what if it recorded the DeviceId/FileId of the folder’s root directory in the folder’s config? This information is available in all environments that Syncthing compiles for. See . This would actually be much safer than using a generic .stfolder marker across all folders.

For example, let’s say a user has two USB disks mounted at D: and E:. The user shares two folders, the first as D:\ and the second as E:\. Both now have an .stfolder marker. If the user (or Windows!) decides to swap the drive letters, both folders would have all their files removed without warning. Or if a new drive D: was added, and the old D:\ now is mounted as E:\, all of the second folder’s files would be deleted.

The same thing could happen on Linux, if a user unknowingly swapped /mnt/d and /mnt/e.

I could whip up a PR to store the DeviceId/FileIds pretty quickly. The tricky part would be how to handle when Syncthing detects the IDs changing.

When that happens Syncthing should probably set the folder as “read only”, then scan the folder and compare it to what’s in its database, and if the two are different, ask the user how to proceed. Right?

1 Like

Personally, I think a simpler solution would be to instead of .stfolder use something like .syncthing_folderID (e.g. .syncthing_udmbc-qrwmp). Changing .stfolder to .syncthing has already been proposed on the forum previously (for better clarity of which software the folder belongs to), and adding the folder ID would make the marker unique to the specific folder.

The largest problem with any such changes though would be backwards compatibility, and also possible breakage of other 3rd tools that may rely on .stfolder being present.

This is just my personal opinion, unconsulted with anyone else, so I have no idea what others may think about a change like this :upside_down_face:. I’m not a fan of gluing the folder to a specific device though, as I myself happen to move folders around quite a bit, and doing so would make my own use case quite annoying.


FileId is also sometimes fictitious (assigned on the fly when the file is opened), like in some encrypted / compressed filesystems on Windows. This made it not reliable for purposes of recursion detection for example.

Indeed .syncthing-$folderID would solve some issues, especially if ignores and stuff where then stored in there as well. But migrating to it is painful, we’ve had a couple of false starts on it.

1 Like

Wouldn’t it be more robust to keep a default filename, but put the folder ID inside as content (.syncthing/folder-id contains abcde-fghij)? That would allow to distinguish between “folder marker missing” and “another ST-shared folder happened to show up under this path”.

I agree that migration is painful, but coupled with other changes like ignore patterns it might become worth it when enough good reasons have been collected.

In general, I think it’s good to distinguish files that are required for internal functionality (folder marker) from files that contain user preference (.stignore). Collecting the former under a common path is wise, but telling users to edit some files inside it but definitely leave others alone is confusing. As a reference, Git has exactly this distinction, cluttering the top-level with e.g. .gitattributes, .gitignore etc. which are all preferences, and maintaining internal data in .git/.

One reason a folder ID specific directory would make sense is because a single directory on disk could be shared as several distinct folders, potentially with separate ignore patterns.

What’s the allowed character set for folder IDs? When a file is named after it, that must be restricted accordingly.