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>
Actualizar un servidor con el agente en una carpeta NO estandar terminaba en
verde y lo dejaba con la version anterior. Todo el camino de Windows
identificaba al agente por NOMBRE, mientras que lo unico que se actualiza se
identifica por RUTA; en cuanto las dos no coincidian, nada fallaba y nada
cambiaba.
- Se alinea la tarea programada con el binario instalado. `Start-ScheduledTask`
ejecuta la ruta registrada en su accion, no el -Prefix: si difieren, se copiaba
el binario nuevo en un sitio y se arrancaba el viejo del otro. Ahora se
reapunta conservando disparador, principal, ajustes y argumentos; si no se
puede corregir, FALLA — arrancar a sabiendas el binario anterior es peor.
- La confirmacion de arranque mira la RUTA del proceso. Un agente viejo que
nunca se detuvo satisfacia igual de bien un `Get-Process -Name`. Si la ruta no
es legible (un proceso de SYSTEM no la expone sin elevacion) se acepta por
nombre y se avisa, en vez de revertir una actualizacion correcta por falta de
informacion.
- Corregido Merge-EnvFile con un config\.env de UNA linea: al asignar la salida
de un `if`, PowerShell desenrolla un array de un elemento a escalar, asi que
$lines.Count reventaba con Set-StrictMode y la siembra abortaba la instalacion.
Nuevo scripts/emular-actualizacion-windows.ps1: monta un agente falso (un .exe
real que se queda vivo), una instalacion en una carpeta y una tarea apuntando a
otra, corre el instalador y dice si la actualizacion surtio efecto. Sin elevacion
y sin tocar la instalacion real de la maquina. Es lo que destapo los dos
defectos: contra el instalador anterior reproduce el sintoma exacto —codigo de
salida 0 y "El agente esta corriendo con el binario nuevo" sobre un servidor
intacto— y contra este confirma que ya surte efecto, sin tocar la tarea cuando
ya estaba bien.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
