Ámbitos de ruta

Las variables

Escribir rutas absolutas en un ámbito no funciona: cambian en cada plataforma y en cada máquina. El plugin de ficheros ofrece variables que se resuelven en tiempo de ejecución:

Los dos comodines

No significan lo mismo y confundirlos es la causa de la mitad de los ámbitos mal escritos:

$APPDATA/proyectos/*      un solo nivel: los ficheros dentro de proyectos/                          NO entra en proyectos/2026/$APPDATA/proyectos/**     recursivo: todo lo que cuelgue, a cualquier profundidad                          SÍ entra en proyectos/2026/enero/notas.txt

La regla práctica: empieza con el de un nivel y sube a recursivo solo si hace falta. Un ámbito recursivo sobre un directorio donde el usuario puede crear estructura concede todo lo que cree ahí en el futuro, que es la pregunta del nivel 27.4.

Y un detalle que sorprende: el comodín no cruza a directorios superiores. $APPDATA/** no incluye el padre de $APPDATA, por muchos comodines que se pongan. Eso está bien y es la primera defensa contra la travesía.

Las cuatro formas de rodear un ámbito

Y aquí está la parte que importa:

La conclusión operativa, y es incómoda: el ámbito de ruta es una buena defensa contra el error y una defensa imperfecta contra alguien que lo intente a propósito. Las dos primeras las para bien; las dos últimas dependen del plugin y del sistema de ficheros.

De ahí las tres reglas que lo hacen sólido:

1 · El ámbito estrecho es la defensa principal. Un ámbito al directorio de la aplicación deja poco margen incluso si alguien encuentra una forma equivalente. Uno al directorio personal deja mucho.

2 · No dependas del ámbito para lo que importe de verdad. Si el daño de salirse fuera grave, la operación no debería aceptar una ruta: debería aceptar un identificador y resolver la ruta el core. Nivel 14.4, otra vez.

3 · Prueba con las formas raras. Un ámbito escrito y no probado con un retroceso, un enlace y una diferencia de mayúsculas es un ámbito que nadie sabe si funciona.

Los ámbitos de escritura son otra cosa

Un aviso que merece separarse: un ámbito de escritura mal puesto es peor que uno de lectura mal puesto. Con lectura, el peor caso es una filtración; con escritura, alguien puede modificar ficheros que después se ejecutan — un script de arranque, una configuración, un fichero que otra aplicación lee.

Por eso conviene que los dos ámbitos sean distintos, aunque el directorio coincida hoy:

{ "identifier": "fs:allow-read",  "allow": [{ "path": "$APPDATA/**" }] },{ "identifier": "fs:allow-write", "allow": [{ "path": "$APPDATA/proyectos/**" }] }

Leer todo lo de la aplicación, escribir solo donde van los proyectos. Es una línea más y la asimetría es la correcta.