Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Syncthing – a continuous file synchronization program

syncthing.net

Post reply on HN
Print view View original

121–130 of 233 posts

Re: Syncthing – a continuous file synchronization program

#121

Post by j1elo »

poisonborz wrote: post #61

I repaced Dropbox with it a year ago and I'm satisfied, it's a great project. But atm I couldn't recommend it to even knowledgeable friends, let alone family members: - Sometimes long-deleted folders pop up when older version clients connect - Syncing or connecting takes sometimes ages to start for no obvious reason, client not giving enough info on what is happening - Relation between clients is not obvious, the pow…

Add to that:

- The handling of ignored files is confusing, to say the least.

I happened to comment about it just some day ago, so to not repeat the comment -> https://news.ycombinator.com/item?id=28760365

Re: Syncthing – a continuous file synchronization program

#122

Post by hparadiz »

grandchild wrote: post #107
hparadiz wrote: post #14

Earlier quoted context omitted.

The thing with the .stfolder file is annoying as hell. I use it to sync the build output folder for my Android builds but sometimes I need to run a clean and it wipes out the folder. Syncthing's developers for whatever reason just can't seem to grasp that sometimes I could careless about a folder's history and just need my files synced. My fix it to run `touch .stfolder` in the build directory which fixes it but seri…

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…

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.

Re: Syncthing – a continuous file synchronization program

#123

Post by j1elo »

deaddabe wrote: post #21

I have switched from Nextcloud to Syncthing. The former was a resource hog that was eating up too much everything on my modest VPS. I share the files on my local network at home between phone, laptop and desktop. My only issues so far: - I need to manually start Syncthing on the devices, whereas Nextcloud was always running on boot. Not sure if I should start it every time, especially on the Android phone which canno…

> [Nextcloud] was a resource hog that was eating up too much everything on my modest VPS.

I've seen comments like this in multiple occasions. Is it really that bad? I guess if there was a flagrant performance bug, it would have been sorted out with time, so the only remaining explanation is that the code is really poorly laid out, or with design flaws that cause so many performance problems for users.

However next to each "it's a resource hog" there is always another comment saying "it works fantastically well", so I never know what to think (sort of trying it myself, but I'm not that interested in the issue)

Re: Syncthing – a continuous file synchronization program

#124

Post by hparadiz »

j1elo wrote: post #115
libeclipse wrote: post #101

Earlier quoted context omitted.

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

Re: Syncthing – a continuous file synchronization program

#125

Post by pjc50 »

hparadiz wrote: post #98
HKH2 wrote: post #51

Earlier quoted context omitted.

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…

> 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?

Re: Syncthing – a continuous file synchronization program

#126

Post by hparadiz »

rkagerer wrote: post #118

Glad to see another option out there for file sync. Browsing the FAQ I noticed: To further limit the amount of CPU used when syncing and scanning, set the environment variable GOMAXPROCS to the maximum number of CPU cores Syncthing should use Are they using an environment variable shared by other Go programs? Seems like bad practice... why aren't they using a variable or or switch that's unique to Syncthing instead?

It's a GO runtime setting. Has nothing to do with Syncthing.

Re: Syncthing – a continuous file synchronization program

#127

Post by makeworld »

KennyBlanken wrote: post #5

Syncthing works brilliantly! The web UI is excellent, warns you when you're about to do something ill-advised, and stuff like QR codes makes adding clients and folders fairly easy. The separation between folders and devices is handled well. You can easily have half a dozen shared folders between several computers with any mix-and-match combination including which one is 'authoritative' and so on. I used to use it on…

> Lots of controls, especially in the forked android client.

Here's that fork: https://github.com/Catfriend1/syncthing-android

You can also search up Syncthing-Fork on Google Play.

Re: Syncthing – a continuous file synchronization program

#128

Post by chmsky00 »

willis936 wrote: post #116
Normal_gaussian wrote: post #112

Earlier quoted context omitted.

You can't publish your own competing app. The desired behaviour requires running a background service (not allowed) that watches arbitrary folders (not allowed).

I guess I'll just have to pay $49.99 a year for iCloud! Why isn't this a lawsuit yet?

Be the change you want to see in the world.

Re: Syncthing – a continuous file synchronization program

#129

Post by hparadiz »

pjc50 wrote: post #125
hparadiz wrote: post #98

Earlier quoted context omitted.

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…

> 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

Re: Syncthing – a continuous file synchronization program

#130

Post by marcellus23 »

willis936 wrote: post #116
Normal_gaussian wrote: post #112

Earlier quoted context omitted.

You can't publish your own competing app. The desired behaviour requires running a background service (not allowed) that watches arbitrary folders (not allowed).

I guess I'll just have to pay $49.99 a year for iCloud! Why isn't this a lawsuit yet?

Because you can buy an android device?
Post reply on HN