Waarom kopieert Remote Sync na het opnieuw verbinden een hele map opnieuw?

Remote synchronisatie kopieert een hele map opnieuw wanneer de client niet langer kan aantonen dat de lokale en externe bestanden hetzelfde zijn.

Na het opnieuw verbinden van een laptop, NAS, aangekoppelde share of externe peer kan de synchronisatiemotor zijn index herbouwen, een andere bestandsysteemidentiteit zien, opgeslagen hashes verliezen, gewijzigde tijdstempels detecteren, hernoemde bestanden als nieuwe objecten behandelen of vergelijken met een verouderde database. De juiste diagnose beschermt eerst beide kopieën en bepaalt vervolgens of de client opnieuw scant, hasht, opnieuw downloadt of daadwerkelijk data opnieuw overdraagt voordat een bibliotheek wordt gereset.

Bevestig of de Client Scant, Hasht of Overzet

Registreer netwerkdoorvoer, schijflezingen, CPU-gebruik, clientstatus en logberichten tijdens het schijnbare opnieuw kopiëren. Een volledige scan of checksum-pass kan urenlang druk lijken zonder de hele map via internet te verzenden.

Een rclone-discussie beschrijft hoe checksum-modus herhaalde checksumverwerking bij elke uitvoering kan veroorzaken. Dat gedrag verbruikt opslag en CPU, maar verschilt van een echte netwerkhertransmissie.

Gebruik overdrachtstellers per bestand of pakkettotalen om het evenement te classificeren. Als alleen metadata en hashes worden gelezen, optimaliseer dan de scanstatus; als volledige payload-bytes opnieuw worden verplaatst, ga dan door met identiteit-, index-, tijdstempel- en hernoemingstests.

Controleer of de Synchronisatiedatabase of Index is Herbouwd

Inspecteer de clientlogs rond het opnieuw verbinden op database-migratie, corruptie, ontbrekende index, reset, herscan of eerste-run berichten. Vergelijk de clientconfiguratiemap en databasetijdstempel met de laatste succesvolle synchronisatie.

Een Syncthing-ondersteuningsgeval legt uit dat een corrupte indexdatabase mogelijk opnieuw opgebouwd moet worden, waardoor het apparaat zich gedraagt alsof mappen nieuw zijn toegevoegd en mogelijk een grote initiële herscan veroorzaakt.

Maak een back-up van de database voordat u deze verwijdert of reset. Als het opnieuw kopiëren direct begon na een app-herinstallatie, containerhercreatie, profielreset of dataverlies, bewaar dan de goede data en gebruik de door de client ondersteunde workflow voor opnieuw verbinden met een bestaande map.

Vergelijk Bestandsidentiteit Verder dan de Bestandsnaam

Kies meerdere bestanden die de client opnieuw wil kopiëren en vergelijk grootte, wijzigingstijd, checksum, permissies, eigendom, hoofdlettergebruik, uitgebreide attributen en pad aan beide zijden. Noteer welk veld verschilt.

FreeFileSync-gebruikers bespreken het opslaan van checksums omdat grootte en tijdstempels alleen niet altijd kunnen bewijzen dat gekoppelde bestanden identiek blijven, terwijl checksumdatabases hun eigen statusvereisten toevoegen. Dit illustreert waarom bestandsvergelijkingsmetadata belangrijk is na het opnieuw verbinden.

Als inhoudshashes overeenkomen maar tijdstempels of permissies verschillen, corrigeer dan klok-, metadata-behoud- of vergelijkingsinstellingen in plaats van inhoud opnieuw over te dragen. Als hashes verschillen, bepaal dan welke zijde gezaghebbend is voordat automatische overschrijving wordt toegestaan.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Controleer of de Map Onder een Andere Identiteit is Opnieuw Verbonden

Vergelijk het aangekoppelde pad, filesystem UUID, netwerkshare-naam, stationsletter, volume-identificatie, container bind mount en hoofdlettergevoeligheid voor en na de verbroken verbinding. Een bekend mappad kan wijzen op een andere mount of een lege lokale map.

Synchronisatietools slaan vaak mapidentiteit op in een lokale database in plaats van alleen op het weergegeven pad te vertrouwen. Een opnieuw aangekoppelde NAS-share, vervangen USB-schijf, gewijzigd Docker-volume of opnieuw aangemaakt clientprofiel kan er dus uitzien als een gloednieuw doel.

Stop met synchroniseren als de verwachte mount afwezig is of de map naar lokale fallback-opslag wijst. Herstel de oorspronkelijke mount en controleer voorbeeldbestanden voordat u de bibliotheek opnieuw verbindt om verwijderingen of dubbele downloads te voorkomen.

Test of Verplaatsingen en Hernoemingen Worden Gedetecteerd

Kies een kleine map, hernoem deze terwijl beide peers verbonden zijn, en observeer of de client een metadata-verplaatsing uitvoert of elk bestand als nieuwe inhoud uploadt. Herhaal na een verbroken en opnieuw verbonden verbinding.

Een Syncthing-functiediscussie merkt op dat verplaatsingen of hernoemingen als nieuwe overdrachten kunnen worden behandeld wanneer het hulpmiddel de gewijzigde paden niet kan matchen via zijn bestaande index, wat verwijder-en-opnieuw-upload-gedrag veroorzaakt.

Als het opnieuw kopiëren volgt op een hernoeming van een map op hoog niveau, laat de client dan zijn indexuitwisseling voltooien voordat u meer wijzigingen aanbrengt. Vermijd voor grote bibliotheken gelijktijdige massale hernoemingen op meerdere peers en houd versiebeheer of back-upbescherming ingeschakeld.

Verbind Veilig Opnieuw Zonder de Goede Kopie te Resetten

Maak een back-up of snapshot van de gezaghebbende zijde, pauzeer synchronisatie en test een kleine submap met de bestaande-map- of herlinkfunctie van de client. Klik niet op een generieke reset- of resync-knop voordat u de richting ervan begrijpt.

De ZimaSpace-gids voor veilig herstellen van één gedeelde map biedt hetzelfde isolatieprincipe om onaangetaste data te beschermen.

Het probleem is pas opgelost wanneer het opnieuw verbinden de index behoudt, bestaande bestanden vergelijkt zonder payloadoverdracht, alleen echte wijzigingen toepast en een nieuwe verbroken verbinding overleeft. Als de database herhaaldelijk corrupt raakt of verdwijnt, los dan het opslag-, afsluit-, containerpersistentie- of clientinstallatieprobleem op in plaats van terugkerende volledige synchronisaties te accepteren.