Software-update: Syncthing 2.1.3

Versie 2.1.3 van Syncthing is uitgekomen. Met dit opensourceprogramma kunnen bestanden tussen twee of meerdere computers kunnen worden gesynchroniseerd. Dit gebeurt zonder dat er een centrale server tussen zit, zoals dat wel het geval is bij opslagdiensten als Dropbox, Google Drive, OneDrive en iCloud. De software is onder meer beschikbaar voor Windows, Linux, macOS, BSD en Solaris. Een onofficiële client voor Android kan hier worden gevonden. Ook zijn er packages voor bijvoorbeeld Synology en QNAP. In deze uitgave zijn de volgende veranderingen en verbeteringen aangebracht:

Fixes

• fix(ignore, fs): allow loading ignore patterns behind symlink (fixes #10785) in #10786
• fix: avoid warning on does-not-exist scan error (fixes #10465) in #10791
• fix(strelaypoolsrv): locking correctness in #10801
• fix(model): properly health-check up-to-date folders (fixes #10546) in #10773
• fix(gui): fix expanding one folder not collapsing others in group in #10809
• fix(gui): add bottom margin to folder action buttons for wrapped spacing in #10728
• fix(upnp): guard against out of index string access in #10834
• fix(ignore): handle pattern resulting in empty string in #10835
• fix(versioner): handle invalid empty command in #10836
• fix(api): handle empty path in static request in #10837
• fix(db, model): better handle db connections, puller concurrency, avoid deadlock (fixes #10841) in #10842

Other

• chore(fs): use x/sys/windows where possible in #10766
• chore(model): simplify FileInfoBatch size computation in #10776
• build: allow inotify on Android amd64 (ref #8710) in #10783
• chore: fix a couple of unclosed http connections in #10806
• chore(gui): lazy-render collapsed panels to reduce watcher count in #10772
• build(deps): update dependencies in #10824
• chore: new code contribution guidelines in #10821
• chore: remove ignore file caching entirely in #10813
• chore: slightly optimise rename detection (ref #10777) in #10819
• chore(gui): better describe when a pending folder/device notification will reappear in #10808
• chore: deflake TestRecvOnlyRevertNeeds in #10827
• chore(model): don't check existing file twice in rename detection in #10833
• chore(fs): optimise casefs caching performance in #10830
• chore(model): optimise fsync calls in #10831
• chore(syncthing): include local db entries in perfstats in #10839

Versienummer	2.1.3
Releasestatus	Final
Besturingssystemen	Android, Linux, BSD, macOS, iOS, Windows 10, Windows Server 2016, Windows Server 2019, Windows 11, Windows Server 2022, Windows Server 2025
Website	Syncthing
Download	https://syncthing.net/downloads
Licentietype	GPL

Reacties (11)

[FPSUsername]

Geweldige software, echter heeft het niet door als je een bestand hernoemd of verplaatst, dan gaat het bestand op de andere client verwijderd en opnieuw gedownload worden.

[rikster]

Kun je uitleggen waarom je dit een bezwaar vindt?

[FPSUsername]

Omdat hernoemen en verplaatsen sneller is dan opnieuw downloaden.

[rikster]

Maar je moet dan toch b.v. wel een fingerprint van die bestanden bijhouden en dat kost tijd, CPU-cycles en RAM. Als bleeding edge snelheid je doel is zou ik eerder uitwijken naar rsync (over SSH, als het extern is) oid. Dat is ook nog veel 'lichter' en stuurt alleen de <delta>.

Ik vind syncthing handig omdat het gemakkelijk door NAT-constructies werkt en omdat ik er versiebeheer op kan toepassen en voor mijn gebruik is dat belangrijk, maar opties verschillen nu eenmaal. Als je b.v. versiebeheer doet door verplaatsen of hernoemen dan moet je misschien wat anders kiezen dan syncthing.

[SilentLucidity]

Dat doet syncthing al. Die bestanden krijgen gewoon een hash en als hij de hash kent zal hij het bestaande bestand hergebruiken.

[beerse]

Sterker, met grotere bestanden gaat die hash over blokken van dat bestand en is het per blok dat de gegevens over gaan.

[Room42]

[...] echter heeft het niet door als je een bestand hernoemd of verplaatst, dan gaat het bestand op de andere client verwijderd en opnieuw gedownload worden.

Dit is niet waar. Misschien heb jij een edge-case, maar hier wordt een 3GiB groot bestand in seconden hernoemd (zonder kilobytes aan netwerkverkeer).

Geweldige software

Daar ben ik het wel mee eens.

[Reactie gewijzigd door Room42 op 5 augustus 2026 17:15]

[FPSUsername]

Wellicht is er ergens een incompatibiliteit. Ik gebruik BTRFS op een ARM64 linux machine en synchroniseer bestanden (two way) naar mijn windows laptop (NTFS) en linux desktop (als ik het me goed herinner EXT4 of ook BTRFS), allebei x64.

Wellicht moet ik iets van een instelling aanpassen?

[beerse]

Als de verplaatsing onder msWindows is uitgevoerd en de sync naar een aantal linux machines is, dan kan het zijn dat de verplaatsing onder msWindows als een copy-paste-remove actie is gebeurt, dat komt nogal wel eens voor. Met grote bestanden is dat te herkennen aan de doorlooptijd.

[beerse]

Dat van het wel of niet herkennen van het verplaatsen van een bestand heeft een aantal afhankelijkheden.

Om te beginnen is het of het filesysteem of het operating systeem de verplaatsing aan syncthing door geeft of dat syncthing zelf ziet of het bestand er op de ene plek niet meer is en op de andere plek een 'nieuw' bestand staat. Onder linux kan ze bijvoorbeeld zien dat het de zelfde inode is. Maar als ik op een desktop met een ssd en een hdd een bestand verplaats van de ene naar de andere dan is dat voor syncthing alleen een verplaatsing als het operating systeem dat aangeeft.

En dan heeft syncthing nog de optie of ze de meldingen van het operatingsysteem moet volgen of niet. En op sommige operatingsystemen krijgt ze die info gewoon niet. Dan is een verplaatsing moeilijk te herkennen.

Uiteindelijk zal syncthing kiezen voor de meest veilige optie, al kost dat mogelijk tijd en bandbreedte.

[RobertMe]

Wat ik eens begrepen meen te hebben is dat het wel ondersteund wordt, maar afhankelijk van de "grote" mis kan gaan. Als je een map hernoemd/verplaatst kan het voor komen dat dit niet wordt herkend maar dit gezien wordt als de oude map verwijderd is en de nieuwe toegevoegd. Vervolgens zit er wel nog een stuk logica in om op basis van de inhoud te herkennen dat het een verplaatst bestand is. Maar als er veel bestanden zijn verplaatst (/toegevoegd en verwijderd) gaat dat niet altijd goed (of wordt dat helemaal niet toegepast?).

En wat volgens mij ook van belang is / kan helpen is als Syncthing is ingesteld om de mappen live te monitoren. Als je dan een map hernoemd of verplaatst dan krijgt die daarvan een seintje dat er een rename heeft plaatsgevonden, i.p.v. dat die er later zelf achter komt dat iets weg is en iets nieuws is toegevoegd.

En daarnaast doet Syncthing niks met partities, en je OS wel. Als je Linux gebruikt en bv je /home/X map in Syncthing zet maar bv /home/X/Pictures op een andere partitie staat en je gaat bestanden verplaatsen van ergens (anders) in die home map naar Pictures dat is dat, doordat je over de partitie (en dus mogelijk ook filesystem) verplaatst altijd een kopieer + verwijder actie. Wat Syncthing dus ook als dusdanig zal zien. Op de nieuwe locatie worden bestanden aangemaakt, en op de oude verwijderd. Simpelweg omdat dat ook is wat op OS niveau plaatsvindt. (I.t.t. het hernoemen of verplaatsen binnen dezelfde partitie, dan blijft het bestand staan en wordt alleen de verwijzing geupdate).