Actualizar a 1.1.4 fallaba con "no escribio config\.version tras la
actualizacion" aunque el binario nuevo estuviera instalado y corriendo desde la
ruta correcta. La causa era el ORDEN dentro de ensure_runtime_layout(): el sello
iba al final, detras del re-despliegue de las deps embebidas (7-Zip y ODBC). Al
cambiar de version esas deps se re-copian ENTERAS, asi que el sello quedaba por
detras de esa copia y del desempaquetado del onefile de ~254 MB con el antivirus
escaneando cada archivo. El PANEL se rendia esperandolo y daba por fallida una
actualizacion que iba bien.
- El sello se escribe lo primero, en cuanto existen las carpetas. Es tambien mas
honesto sobre lo que significa —"que binario esta corriendo"—, que es cierto
desde que el proceso arranca. El sello de DEPS sigue yendo al final, donde su
comentario explica por que: si la copia falla a medias, el proximo arranque
reintenta en vez de quedar marcado como al dia.
- La version va en la PRIMERA linea del log de arranque. Permite comprobar que
binario corre de verdad mirando solo config/logs, sin depender del sello ni del
reporte al panel: verificar una actualizacion deja de obligar a creerse lo que
diga otro sistema.
La prueba nueva observa el estado del sello EN EL MOMENTO en que empieza la copia
de deps, no al final, que es la unica forma de fijar el orden. Comprobado que
muerde: devolviendo el sello al final falla con `assert None == '1.1.5'`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sustituye a 1.1.3, cuyo artefacto publicado se genero antes de los arreglos: su
install.ps1 no traia -UpdateInPlace y su binario llevaba el runner.py que ignora
--headless en Windows. Actualizar con el mataba el agente, cambiaba la tarea
programada a SYSTEM y la dejaba sin arrancar, porque Qt no puede crear su
plataforma como SYSTEM en la sesion 0 sin offscreen.
Se quema el numero en lugar de reemplazar 1.1.3 con --force: los paquetes
genericos de Gitea son inmutables, y dos contenidos distintos con la misma
version fue exactamente lo que hizo caro el diagnostico.
Hay que reconstruir los binarios aunque el codigo ya estuviera arreglado, porque
__version__ va compilado dentro del ejecutable y el PANEL compara el sello
config/.version contra la version que creia estar instalando.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Esa ruta es el peor caso posible y existe en produccion: la ruta por omision
C:\Aduanasoft\CloudRestoreAS es PREFIJO DE CADENA de ella, asi que cualquier
comparacion hecha con startsWith daria por iguales dos instalaciones distintas
— y el resultado seria el fallo silencioso otra vez, actualizar una carpeta y
arrancar la otra.
El flujo ya la manejaba bien (Test-SamePath compara por igualdad exacta tras
normalizar), pero nada lo probaba: la emulacion usaba declarada/otra-carpeta,
nombres sin relacion entre si, que un startsWith mal puesto pasaria sin problema.
- Escenario `sufijo` en emular-actualizacion-windows.ps1: instalacion en
...\CloudRestoreAS-win y tarea apuntando a ...\CloudRestoreAS. Verificado en
Windows: reapunta la tarea, el proceso queda corriendo desde -win y el sello en
la version nueva.
- Nuevo scripts/probar-funciones-install.ps1: extrae las funciones del instalador
por AST y las ejercita contra una tarea simulada, sin elevacion. Cubre los casos
limite de la comparacion de rutas (el par de prefijo en ambos sentidos, comillas,
barra final, mayusculas, `..`, ruta vacia) y que Sync-AgentTaskPath falle cuando
no puede corregir.
BUILD.md documenta por que se compara por igualdad exacta y no por prefijo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
