Autojump: Las entradas de la base de datos se borran con regularidad

Hola,

El mismo problema aquí, excepto que creo que solo sucede después del reinicio.

Probablemente arreglado por https://github.com/wting/autojump/pull/383

Aparentemente no arreglado. Esto es realmente molesto. Alguna idea ?

Perdón por la respuesta tardía, pero tengo una idea aproximada de lo que está sucediendo y cómo solucionarlo.

En cada cambio de directorio, el salto automático bloquea el archivo de datos y actualiza una entrada, almacenada en un formato similar a una "base de datos". Hay una condición de carrera (agravada por scripts / comandos de shell que atraviesan directorios como find ) donde el bloqueo falla y la base de datos se sobrescribe.

La forma correcta de solucionarlo es:

1. Corrija el bloqueo del archivo para que sea seguro en condiciones de carrera.
2. Cambie de un formato similar a una base de datos a un registro de solo anexar (como .bash_history , .zsh_history , etc.), y solo calcule los pesos cuando alguien invoca el salto automático para cambiar de directorio (también conocido como j ).

Hmm, acabo de mirar el código y no veo ningún bloqueo real.
Además, la copia de seguridad se realiza justo después del movimiento del archivo temporal a la base de datos real, por lo que si el movimiento falló (no hay verificación de errores), estamos haciendo una copia de seguridad de un archivo vacío.

Supongo que mejorar esto no debería ser tan difícil.

Tal vez # 383 no protegió todos los lugares con flock , pero hay un enfoque más simple, pero simplemente envuelve todo autojump dentro de flock , como:
alias autojump='flock /tmp/autojump.lock autojump'

@trou, ¿puedes probar esto?

_UPD: solucionar problema de sintaxis_

Lo acabo de agregar a mi bashrc, ya veremos.

No parece ayudar :(

Hm, ¿cómo puede suceder esto?
¿La máquina se apagó de forma anormal (es decir, mediante el botón de encendido)?

También tal vez autojump llamado desde sh regular (en lugar de bash ) en
¿paralelo? Dado que en este caso el alias de bash no funcionará, y en este caso
puede intentar envolverlo a través de un script, algo como:
mv /usr/bin/autojump{,.orig}
echo "bandada /tmp/autojump.lock autojump.orig"> / usr / bin / autojump

O me estoy perdiendo algo por completo.

No lo sé, pero el problema debería solucionarse en el código de todos modos.

He estado usando autojump durante aproximadamente un año y, de repente, parece que limpió todo el historial. Mirando ~ / .local / share / autojump, veo que se creó un nuevo archivo. Vi https://github.com/wting/autojump/issues/208 , que apunta aquí. Estoy usando:
autojump-22.3.2-1.fc24.noarch

¿Alguna otra información de depuración que pueda proporcionar?

También tengo esto regularmente, ¿hay alguna manera de depurar esto?

@wting : Mencionaste que una forma de resolver el problema podría ser cambiar a un "registro de solo anexar" y calcular los pesos cuando se ejecuta el salto automático.

Supongo que está evitando esta solución porque el registro puede volverse prohibitivamente largo con el tiempo. (Y, también, porque sería bueno si el sistema existente funcionara de la manera que creemos que debería hacerlo).

¿Pero quizás sea posible una solución híbrida? Agregue entradas a un registro, pero agregue un comando de salto automático que las convierta al formato de la base de datos. Cuando se ejecuta el salto automático, consulte tanto el registro como la base de datos para calcular los pesos reales.

La principal desventaja de esto es que requiere que el usuario colapse la base de datos manualmente. Una solución alternativa sería hacer una prueba aleatoria cada vez que se ejecuta el salto automático para determinar si la base de datos debe colapsarse. Esto, al menos, disminuiría las probabilidades de una condición de carrera.

@azat : Voy a probar tu solución.

Desde que implementé un parche propuesto en el n. ° 482, no he experimentado este error.

Sin embargo, también estoy interesado en escuchar los resultados de @ r-barnes. Si tiene éxito, ¿hay alguna razón por la que este "bloqueo anticipado" no se pueda utilizar en el salto automático?

¡Argh! Obtuve una actualización que sobrescribió el parche del # 482. Ocurrió en el siguiente reinicio. No entiendo cómo otras personas no están experimentando esto. Me pasa constantemente.

No tuve un 100% de éxito con el # 482. La base de datos todavía parece limpiarse o, quizás, su tamaño es limitado. Para mí, no parece crecer mucho más allá de las 23 entradas.

Tuve un 100% de éxito con el # 482. 21 de abril hasta el 25 de julio. Actualmente tengo 279 entradas. Esto sugiere que nuestras situaciones son diferentes, lo que significa que hay varios factores desencadenantes de este error. Lo que sea que esté haciendo que lo cause, siempre está relacionado con los diferentes sistemas de archivos que usa autojump para administrar la base de datos, como sugirió @Frefreak . Y, tal como sugerí, podría haber múltiples rutas de código que conduzcan al mismo error, algunas de las cuales nunca las uso, pero tú sí.

Ah, sucedió de nuevo algún día la semana pasada, después de tanto tiempo desde la última vez que se eliminaron 349 entradas, el tamaño del archivo se redujo de 93K a 77K.

¿alguna actualización?

Terminé desarrollando mi solución (solo zsh). Mucho más pequeño, más útil y más confiable :)
https://github.com/kurkale6ka/zsh (el archivo README en ese enlace)

Parece que aquí hay varias alternativas existentes. Estoy probando 'fasd' ahora https://github.com/clvv/fasd , que es solo uno.

Consulte https://github.com/rupa/z/issues/198 - informe de error similar en otro proyecto que tiene un problema similar.
No puedo encontrar una solución similar a un salto automático que funcione :(

Para su información, no he tenido este problema durante más de un año después de cambiar el archivo temporal al mismo directorio que el archivo de datos. El parche es:

--- autojump_data.py    2018-09-07 15:28:30.488681864 +0800
+++ /usr/bin/autojump_data.py   2017-08-26 15:43:50.136781805 +0800
@@ -120,11 +120,12 @@

 def save(config, data):
     """Save data and create backup, creating a new data file if necessary."""
-    create_dir(os.path.dirname(config['data_path']))
+    data_dir = os.path.dirname(config['data_path'])
+    create_dir(data_dir)

     # atomically save by writing to temporary file and moving to destination
     try:
-        temp = NamedTemporaryFile(delete=False)
+        temp = NamedTemporaryFile(delete=False, dir=data_dir)
         # Windows cannot reuse the same open file name
         temp.close()

Mover archivos entre dispositivos no es atómico (realiza una operación de copia + eliminación) por lo que deben colocarse en el mismo dispositivo para sobrescribirlos atómicamente.

Eso tiene mucho sentido para mí. Un movimiento solo es atómico si está en la misma partición ...

Esto se implementa en v22.5.2 aquí: https://github.com/wting/autojump/commit/bc4ea615462adb15ce53de94a09cec30bcc5dc0a

Por ahora, instale y pruebe desde la fuente e informe si aún se pierden datos.

Descubrí que en realidad abrí una solicitud de extracción n. ° 495 con el cambio el año pasado, pero pasó desapercibido.

Vaya, revirtí https://github.com/wting/autojump/commit/bc4ea615462adb15ce53de94a09cec30bcc5dc0a y fusioné tus cambios en https://github.com/wting/autojump/commit/8fffbad95ac5626f4d9688276ba33e36808.

No estoy seguro de si el tiempo es suficiente para las pruebas, pero no tengo problemas con la limpieza de la base de datos. ¿Qué piensas @wting. Y si es adecuado para usted, ¿puede crear una nueva versión para que las distribuciones puedan recogerla?

Empecé a sufrir este problema de limpieza. Después de varias horas, autojump.txt se borra. ¿De todos modos para depurarlo?

Recientemente noté que el salto automático no funcionaba como se esperaba. Luego verifiqué para encontrar:

[hendry<strong i="6">@t480s</strong> ~]$ wc -l ~/.local/share/autojump/autojump.txt
35 /home/hendry/.local/share/autojump/autojump.txt

Er ... parece que se ha reiniciado. Alguna idea POR QUÉ?

Había una condición de carrera que ocasionalmente borraba la entrada de la base de datos que se corrigió en v22.5.3.

@minjang , @kaihendry : ¿Pueden ejecutar autojump -v y compartir el número de versión que aparece? Si es menor que esa versión, actualice y / o instale desde la fuente.

[hendry<strong i="5">@t480s</strong> ~]$ autojump -v
autojump v22.5.1
[hendry<strong i="6">@t480s</strong> ~]$ pacman -Qi autojump
Name            : autojump
Version         : 22.5.1-2
Description     : A faster way to navigate your filesystem from the command line
Architecture    : any
URL             : https://github.com/wting/autojump
Licenses        : GPL3
Groups          : None
Provides        : None
Depends On      : python
Optional Deps   : None
Required By     : None
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 121.00 KiB
Packager        : Felix Yan <[email protected]>
Build Date      : Sat 10 Nov 2018 06:58:45 AM
Install Date    : Wed 14 Nov 2018 08:57:48 AM
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

Soy un usuario de Archlinux por cierto: rofl:

En 18.04.2 LTS, tengo v22.5.1. No estoy seguro de si la actualización llegó a los repositorios de Debian / Ubuntu, o si la versión se ha congelado. Actualización instalada: ¡ya veremos cómo va! (Muchas gracias.)

No estoy seguro de quién mantiene el paquete Debian para autojump en estos días, pero es posible que solo se construyan a partir de etiquetas estables. Si bien la rama maestra ha estado en v22.5.3 durante> 6 meses, solo etiqueté v22.5.3 esta noche.

Su mejor opción para lidiar con esta pérdida aleatoria de datos es instalar desde la fuente siguiendo estas instrucciones .