Syncthing 2.1 en bodegas: carpetas, equipos y versión
Mini-caso para bodegas con cuadrillas y depósitos: sincronización local, Device ID, versionado, permisos y prueba de recuperación.
Antes, la báscula y el depósito copiaban remitos por chat; después, cada carpeta tuvo equipo, permiso y versión. En una bodega exportadora de Luján de Cuyo, el problema aparece cuando cuadrillas, báscula y administración trabajan con archivos pequeños que cambian durante el día. Syncthing 2.1.3 sincroniza carpetas entre dispositivos autorizados. Este caso muestra qué carpeta crear, quién toca cada equipo y cómo probar recuperación.
Dónde aparece la carpeta con dueño borroso
El caso empieza con cuatro notebooks, una tablet de campo y una PC de administración. Los archivos son simples: remitos escaneados, planillas de cosecha, controles de báscula y fotos de etiquetas de pallets. El antagonista es la carpeta compartida sin dueño: acepta cambios de cualquiera y conserva pocas pistas cuando aparece una versión vieja. La release v2.1.3 de Syncthing fue publicada el 5 de agosto de 2026. El repositorio syncthing/syncthing registraba 87.344 estrellas, 5.394 forks y licencia MPL-2.0 al momento de esta corrida. Esa escala no reemplaza el diseño local; muestra que la herramienta tiene comunidad, código visible y documentación mantenida. El detalle de estatus fue una etiqueta blanca pegada en la tablet de báscula, escrita con marcador fino: BASC-02. Ese objeto ordenó la conversación. Cada equipo necesitaba nombre, responsable y carpeta permitida antes de sincronizar un solo archivo. El dato puente vuelve a Stack Overflow 2025: PostgreSQL figura con 55,6% entre bases usadas y SQLite con 37,5%. En una operación chica, esa familiaridad permite separar dos trabajos: Syncthing mueve archivos entre dispositivos; una base o planilla controlada guarda responsables, cierres y auditoría de entregas.
Cómo funciona por dentro Syncthing compara archivos por bloques, calcula hashes SHA-256 y transmite cambios entre dispositivos conectados.
Cada dispositivo se identifica con un Device ID derivado de su certificado. El tráfico entre equipos usa TLS, y cada dispositivo compara huellas contra una lista aceptada. Una carpeta puede ser de envío y recepción, solo envío o solo recepción, según el flujo operativo. 1. Sistemas nombra cada equipo y registra su Device ID. 2. Administración crea carpetas por proceso: báscula, depósito y exportación. 3. Cada carpeta define dispositivos autorizados y tipo de sincronización. 4. Syncthing detecta cambios por watcher y escaneo horario. 5. El versionado conserva copias anteriores cuando otro equipo reemplaza un archivo. 6. Una tabla externa guarda responsable, cierre diario y observaciones. 7. El backup copia carpetas, configuración y registro; una restauración recupera versión y dueño. La documentación de sincronización explica que Syncthing conserva versiones local, remotas y globales para decidir qué archivo debe quedar vigente. La guía de versionado permite guardar copias anteriores por carpeta; por defecto, no conserva versiones viejas. La página de seguridad recuerda que un dispositivo perdido debe revocarse desde los demás.
Qué se instala o configura primero
El primer entregable verificable es un piloto con tres carpetas, cinco dispositivos y veinte archivos de prueba. Cada carpeta tiene dueño, tipo, dispositivos permitidos, estrategia de versionado y prueba de corte. La pila usa Syncthing 2.1.3, usuarios locales del sistema, disco cifrado en equipos móviles, backup S3 con Rclone o Restic, planilla de responsables y una revisión semanal de conflictos. La referencia de configuración muestra opciones: fsWatcherDelayS, carpetas ignoradas, dispositivos no confiables y límites por equipo. El punto técnico más delicado es la configuración propia de Syncthing: sincronizarla entre equipos puede terminar con dos dispositivos usando el mismo Device ID, síntoma que la documentación advierte como error de operación. Con dólar oficial vendedor a ARS 1520, el costo de un piloto de 16 a 28 horas técnicas a USD 30/h queda entre USD 480 y USD 840, es decir entre ARS 729.600 y ARS 1.276.800. Incluye alta de equipos, carpetas, versionado, exclusiones, backup, capacitación y restauración. Quedan fuera compra de notebooks, soporte de red rural y archivo histórico completo. UMSA puede aplicar este patrón cuando la organización necesita sincronizar archivos chicos sin entregar todo el circuito a una nube externa. El cierre del piloto debe incluir un inventario de equipos, una carpeta recuperada y una revocación de dispositivo documentada.
Dónde se rompe y cómo probarlo
El primer riesgo es borrar desde el equipo equivocado. La señal aparece cuando un archivo desaparece en todos los dispositivos después de limpiar una carpeta local. La prueba activa versionado, borra un remito de ensayo y recupera la copia desde .stversions. El segundo riesgo es equipo perdido con acceso vivo. La señal es un Device ID que sigue autorizado después de cambiar de turno o proveedor. La prueba revoca un dispositivo, intenta conectar y revisa que los demás rechacen la huella. El tercer riesgo es conflicto de edición. La señal aparece cuando dos personas cambian el mismo archivo y Syncthing crea un archivo sync-conflict. La prueba edita una planilla desde dos equipos, documenta el conflicto y define quién cierra la versión vigente. El archivo compartido sirve cuando la bodega puede decir qué equipo lo creó, qué versión quedó y cómo volvió después de una falla.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.