yes the .stfolder is a minor nuisance most of the time, but it's a lifesaver if for some reason or other your folder gets removed or a mounted device is no longer there, or one of a hundred other things that can go wrong with a folder.

then you _really_ want syncthing to stand back and hold its hands up, instead of syncing deletion events to all connected devices or sending all your friends your entire home directory or something like this.

imo, it's a good safety tradeoff, and like so many of those (e.g. short vs long passwords) they might seem annoying most of the time, but prevent incredible damage that _one_ other time.

I understand all these things because I've done this professionally for quite some time. However I've just explained that this is my build directory which means it can be deleted and I won't care. Every build quite literally overwrites all the output files so it's destructive by it's very nature. Syncthing already has an option where it won't sync deletes as well. I just don't understand why it must absolutely have an stfolder path. There should be a destructive sync option where it won't care and will just sync.

I suggest you put your build folder inside a synced folder, instead of syncing the build folder directly.

This is actually exactly what I started to do. Was just kind of annoying :)

If you put a non-empty placeholder file in that folder, it won't be empty any more, so it shouldn't be removed.

Yea but it doesn't matter. The clean from gradle deletes the folder entirely and creates a new one in it's place. I don't care. Just sync the path. That's all I need. Instead Syncthing literally stop syncing ALL folders because "oh no something went wrong".

For whatever reason open source software always has these weird edge case engineering "solutions" that really aren't that great. If someone was actually a paying customer and asked for this the engineers would just figure something out instead of making excuses for why it is the way it is.

> The clean from gradle deletes the folder entirely and creates a new one in it's place.

Maybe it's possible to .. not do that?

You expect me to not use a basic feature of a compiler?

o_O weird take but k

If a build system produces an adverse outcome, it is often possible to customize it so that it does not delete things which you would rather not have deleted. (I've no idea whether this is specifically easy or not in gradle)

It's easy to open a pull request instead of complaining

Commercial products usually aim to satisfy its paying customer's needs. FOSS is, not always but most times, about satisfying one's own needs. So it won't be that easy to change a developer's mind who is determined about their way of doing things even if it is not the best way for others.

It's also kind of arrogant of FOSS advocates to say "just make a pull request" whenever there's criticism of anything FOSS. You could spend weeks working on something only to have the maintainer say no and I've seen this happen and every time it does I just think to myself "welp there's another person who will never make another pull request again".

As a FOSS maintainer I always try to make it clear that before trying your luck with a PR, you should always first engange in a conversation with me.

Seems kind of obvious to my eyes, asking, talking, discussing about some change before doing the actual work. But as it seems, "obviousness" is in the eye of the beholder...

That's fine and all except that the typical refrain from internet folks is that if something is free then you are not allowed to critique, comment, or request changes. If you really care about freedom you can handle a little bit of online banter.

No one is saying you're not allowed to critique the software. You're critiquing the people who create that software for free

Then fork it? No one is stopping you.

I assume you don't care about missing out on updates since that's the free work you're complaining about