Jest: condición de carrera de escritura en caché en todos los procesos

¿No está esto relacionado? https://github.com/facebook/jest/pull/4432

No lo creo. Creo que el caso que vemos en nuestro repositorio es exactamente el mismo archivo que se simula para 2 procesos diferentes (mientras se ejecuta en paralelo), lo que hace que la operación de escritura en caché falle porque un proceso tiene el archivo bloqueado. Ese ticket se parece más a archivos diferentes con el mismo contenido. No tenemos ninguno de esos casos en los repositorios que alojamos en los que encontramos este problema.

Básicamente, nos encontramos con el mismo problema con nuestras pruebas. Una forma fácil de reproducir era eliminar la broma cacheDirectory para forzar la generación de caché en la siguiente ejecución.
`` No se pudo ejecutar el conjunto de pruebas

jest: failed to cache transform results in:

C: / myniceproject / src / jest-cache / jest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b / 3f / settingsProvider_3f1439e55275a795ec8fd32
Mensaje de error: EPERM: operación no permitida, renombrar
'C: \ myniceproject \ srcjest-cachejest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b \ 3f \ settingsProvider_3f1439e55275a95dc8.1db30729
->
'C: \ myniceproject \ srcjest-cachejest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b \ 3f \ settingsProvider_3f1439e55275a95ec8fdb7

Tener el mismo problema y no encontrar una forma de solucionarlo. Jest es básicamente inutilizable para nosotros así.

Estamos intentando actualizar a 21.2.0 desde 20.0.4 y ahora tenemos el siguiente error en nuestros servidores de compilación:

Test suite failed to run
[13:46:50]
[13:46:50]    jest: failed to cache transform results in: C:/TeamCity/buildAgent/temp/buildTmp/jest/jest-transform-cache-c60bb8ad55f1dbc29115038800657f2f-4895fc34da3cd9ad1e120af622bca745/3b/fe-selectors_3b56db772e798e2e4d0c9fc7c9e4a770
[13:46:50]    Failure message: EPERM: operation not permitted, rename '...\jest\jest-transform-cache-c60bb8ad55f1dbc29115038800657f2f-4895fc34da3cd9ad1e120af622bca745\3b\fe-selectors_3b56db772e798e2e4d0c9fc7c9e4a770.1701848979' -> '...\jest\jest-transform-cache-c60bb8ad55f1dbc29115038800657f2f-4895fc34da3cd9ad1e120af622bca745\3b\fe-selectors_3b56db772e798e2e4d0c9fc7c9e4a770'
[13:46:50]      
[13:46:50]      at Object.fs.renameSync (fs.js:772:18)
[13:46:50]      at Function.writeFileSync [as sync] (node_modules/write-file-atomic/index.js:192:8)

Ahora tengo el mismo problema, las pruebas se rompen al azar.

Si ejecuto las pruebas con el indicador --runInBand, como se esperaba, todo está bien.

Puedo ver el mismo problema de manera bastante consistente:

  ● Test suite failed to run

    jest: failed to cache transform results in: .../jest-transform-cache-...
    Failure message: EPERM: operation not permitted, rename '...' -> '...'
        at Error (native)

      at Object.fs.renameSync (fs.js:810:18)
      at Function.writeFileSync [as sync] (node_modules/write-file-atomic/index.js:192:8)

broma 21.2.1
nodo 6.11.1
SO Windows

--no-cache no ayuda y jest-transform-cache todavía se está escribiendo. Lo único que ayuda es --runInBand , que no es aceptable para proyectos grandes.

¿Hay algo que podamos hacer para ayudar a diagnosticar el problema? ¿Debería crear un caso de reproducción?

¿Es este error crítico? ¿Puede tratarse como una advertencia en lugar de eliminar todo el conjunto de pruebas? ¿Hay alguna forma de retroceder y volver a intentarlo?

Tener una pequeña repro sería genial

Aquí está la reproducción: https://github.com/asapach/jest-cache-issue/
Ejecuta efectivamente lodash-es a través de babel-jest para llenar la caché de transformación.
Esto me falla el 80% del tiempo en dos máquinas diferentes (Win8.1 y Win10).
Si elimina --no-cache , falla el 100% de las veces. Agregar --runInBand lo reduce al 0%.

(Por curiosidad, intenté ejecutarlo en WSL en Win10 y el problema no se puede reproducir con la API de Posix)

¿Esto solo está sucediendo en Windows? No tengo acceso a las máquinas de Windows más allá de las máquinas virtuales, por lo que no es el más fácil de depurar para mí ...

@jeanlauliac , agregaste write-file-atomic en # 4088, ¿podrías ayudar?

Este problema es muy similar a https://github.com/npm/write-file-atomic/issues/10 y https://github.com/npm/write-file-atomic/pull/22.

Acabo de ejecutar un seguimiento de procmon , aquí hay un ejemplo del problema:

Hora del día | Nombre del proceso | PID | Operación | Camino | Resultado | Detalle
- | - | - | - | - | - | -
16: 54: 43.2304011 | node.exe | 7624 | SetRenameInformationFile | ... \ constant_ee286bbcf367680ce61a90e506522f92.82986661 | ÉXITO | ReplaceIfExists: True, FileName: ... \ constant_ee286bbcf367680ce61a90e506522f92
16: 54: 43.2305499 | node.exe | 8208 | SetRenameInformationFile | ... \ constant_ee286bbcf367680ce61a90e506522f92.103872574 | ACCESO DENEGADO | ReplaceIfExists: True, FileName: ... \ constant_ee286bbcf367680ce61a90e506522f92

Como puede ver, dos procesos están intentando cambiar el nombre del mismo archivo con 1 ms de diferencia entre sí y el segundo falla.

Creo que npm / write-file-atomic # 22 aborda la versión asíncrona de writeFile() , pero writeFileSync() todavía se ve afectado.

¿Sería posible crear una reproducción que muestre que el solo uso de write-file-atomic en worker-farm contra el mismo archivo falla de alguna manera? Sería genial abrir un problema contra ese proyecto, ya que creo que ahí es donde debería estar la solución.

¿O si pudiera escribir una prueba dentro de broma que muestre el mismo error (tenemos appveyor CI) que también podría ser un comienzo?

Ni siquiera estoy seguro de qué comportamiento queremos en caso de este error. ¿Reintentar la escritura? ¿Volver a ejecutar la prueba? ¿Todo el archivo de prueba?

Bien, intentaré crear otra reproducción. No estoy seguro de que sea posible crear una prueba de broma, porque requeriría generar múltiples procesos, deshabilitar / limpiar la caché y seguir ejecutándose hasta que falle.

Ni siquiera estoy seguro de qué comportamiento queremos en caso de este error.

Bueno, en primer lugar, el problema ni siquiera debería ocurrir cuando --no-cache está activado, ya que el caché no debería estar lleno.
En segundo lugar, no estoy seguro de que sea posible volver a intentar la operación de sincronización correctamente: ¿es posible usar writeFile() lugar de writeFileSync() ? De esa manera, write-file-atomic debería reintentar automáticamente (crearé una prueba para confirmar).

Bueno, en primer lugar, el problema ni siquiera debería ocurrir cuando --no-cache está activado, ya que el caché no debería estar lleno.

Ese es un buen punto y debería solucionarse por separado. De esa manera, --no-cache puede al menos ser una solución.

En segundo lugar, no estoy seguro de que sea posible volver a intentar la operación de sincronización correctamente: ¿es posible usar writeFile() lugar de writeFileSync() ?

¿@cpojer piensa en hacer que no esté sincronizado? No estoy seguro de cómo escala eso. O si tiene otra idea sobre cómo solucionar este problema

• --no-cache es más como --reset-cache realidad. Significa que no usará la caché existente, pero seguirá escribiendo caché. Me gustaría retener eso.
• Estas operaciones tienen que estar sincronizadas, porque ocurren durante llamadas require en el código de usuario, por lo que no podemos cambiar eso.

Aquí está la otra reproducción con worker-farm y write-file-atomic : https://github.com/asapach/write-atomic-issue

Hallazgos hasta ahora: la versión de sincronización falla como se esperaba, pero sorprendentemente la versión asíncrona también falla. Esto significa que probablemente implementen una cola de reintentos solo cuando se ejecuta en el mismo proceso, lo que no ayuda en nuestro caso.

Me gustaría retener eso.

Nueva bandera? Es un nombre muy engañoso. Y en, por ejemplo, CI rara vez desea la caché de todos modos, por lo que solo se desperdician recursos. ¿O se genera un caché dentro de una única ejecución de prueba durante --no-cache , y solo ignora los cachés existentes?

Aquí está la otra reproducción con worker-farm y write-file-atomic

¡Increíble! ¿Podría abrir un problema contra write-file-atomic? Parece que una solución debería ir allí, y si no (no quieren admitir la escritura de varios procesos a la vez) podemos volver a visitar de nuestro lado. WDYT?

Un parche que probé localmente y que parecía funcionar ignora el error si se trata de intentar cambiar el nombre a un archivo con el mismo contenido. Dado que solo significa que otro proceso 'ganó' la carrera, podemos ignorarlo y seguir adelante.

const cacheWriteErrorSafeToIgnore = (
  e: Error,
  cachePath: Path,
  fileData: string,
) => {
  if (
    e.message &&
    e.message.indexOf('EPERM: operation not permitted, rename') > -1
  ) {
    try {
      const currentContent = fs.readFileSync(cachePath, 'utf8');
      return fileData === currentContent;
    } catch (e) {
    }
  }
  return false;
};

@SimenB , seguro, presentaré un problema.

@cpojer , ¿se puede tragar / ignorar este error y tratarlo como una advertencia? Implica que el archivo ya se ha escrito y no se deben perder datos.

Problema ascendente: npm / write-file-atomic # 28

Creo que esto significa que "renombrar" no es una operación atómica en Windows, por lo que rompe la suposición hecha por write-file-atomic . A menos que haya una marca que pueda habilitarse en el nivel de la API de Windows, esto podría significar que es imposible tener escrituras / cambios de nombre atómicos en Windows por completo.

@jwbay, ¡ tu solución me parece razonable! 👍 Sin embargo, en lugar de usar indexOf , usaría e.code === 'EPERM' (más robusto, no depende de un mensaje específico). No creo que debamos volver a leer el archivo para verificar el valor, porque esto podría introducir problemas de concurrencia adicionales (por ejemplo, si el archivo está siendo escrito por otro proceso al mismo tiempo). ¿Le importaría enviar un PR, por favor?

Estaba a punto de comenzar a trabajar en un PR por write-file-atomic en la línea de "si se nos pide que escribamos una sincronización de archivos pero ya está en la cola para ser escrito async, rescatar" (tal vez con una opción para activar el comportamiento). Pero si estamos felices de manejar esto al nivel de Broma, no me apresuraré. cc @jeanlauliac

Estaba a punto de comenzar a trabajar en un PR para write-file-atomic en la línea de "si se nos pide que escribamos una sincronización de archivo pero ya está en la cola para ser escrito async, rescatar" (tal vez con una opción para activar el comportamiento).

Creo que agregar esta lógica (cola local) no solucionaría el problema, porque ocurre principalmente cuando diferentes procesos intentan escribir (cambiar el nombre a) el mismo archivo.

Para solucionar los problemas de concurrencia de una vez por todas, es posible que tengamos que reconsiderar cómo hacemos el almacenamiento en caché, por ejemplo, tener un solo proceso que acceda a la caché, con el que nos comunicamos a través de algún tipo de IPC. Los sistemas de almacenamiento de clave / valor existentes pueden ser útiles, como memcached .

Creo que agregar esta lógica (cola local) no solucionaría el problema, porque ocurre principalmente cuando diferentes procesos intentan escribir (cambiar el nombre a) el mismo archivo.

Ah, quizás entendí mal el tema entonces. De la forma en que lo leí, la biblioteca ya tiene un mecanismo de cola que funciona muy bien para las solicitudes asíncronas, pero si mezcla solicitudes de sincronización _también_ puede obtener colisiones.

Mi solicitud de extracción mencionada anteriormente debería resolver este problema. ¡Al menos lo hizo por mí!

@mekwall , creo que están usando rename() en la versión asíncrona de writeFile() , y todavía falla en mi prueba: https://github.com/asapach/write-atomic-issue. ¿Podría intentar ejecutar mi reproducción? Creo que su cambio podría minimizar la probabilidad de que ocurra este problema, pero no lo elimina por completo.

@asapach ¿Intentaste con mis cambios? Porque lo intenté varias veces, y nunca obtuve EPERM: operation not permitted, rename con mis cambios y siempre lo obtenía sin ellos.

@mekwall , sí, sigue fallando con sus cambios (aunque de forma asincrónica). (Corregido a continuación).

O más bien técnicamente no falla (porque el flujo de sincronización no se interrumpe), pero la consola todavía está llena de errores EPERM.

@asapach Encontré el problema que tienes. Está en el polyfill graceful-fs . Publiqué una solución en este PR: https://github.com/isaacs/node-graceful-fs/pull/119

@mekwall , sí, esto parece solucionar el problema: no más errores en las versiones de sincronización y asíncrona.
El problema ahora es que los archivos temporales no se eliminan, porque fs.unlinkSync(tmpfile) nunca se llama: https://github.com/npm/write-file-atomic/pull/29/files#diff -168726dbe96b3ce427e7fedce31bb0bcR198

@asapach Agregué desvincular a graceful-fs renombrar, pero no estoy seguro de si ese es el camino correcto a seguir. Afaik fs.rename usa la función MoveFile y eso no debería copiar el origen al destino. La fuente debería simplemente cambiar de nombre y la fuente y el destino nunca deberían existir al mismo tiempo.

@mekwall , eso ayuda un poco, pero en algunos casos si el trabajador es despedido antes de tiempo (porque todo el trabajo está hecho), algunos archivos no se limpian, ya que no espera la limpieza. La versión asincrónica parece funcionar bien.

@asapach No está funcionando como se esperaba en absoluto. Necesito sumergirme en las entrañas del nodo para descubrir cómo está funcionando realmente y cuál debería ser el comportamiento previsto. Creo que el objetivo de graceful-fs es hacer que funcione igual en todas las plataformas, así que profundizaré en eso. Al menos hemos encontrado al culpable :)

@asapach Me di cuenta de que mi PR de write-file-atomic no funcionaría, así que tomé otro enfoque agregando fs.renameSync en graceful-fs con las mismas soluciones que fs.rename pero bloqueando. ¡Esto hace que su prueba funcione como se esperaba!

@mekwall , Gracias, he verificado tus cambios en mis dos casos de reproducción y ninguno de ellos falla.
Creo que, en el lado negativo, veo un mayor uso de CPU y disco para la sincronización, pero probablemente sea lo esperado.

Muchas gracias por recoger esto y ayudarnos a solucionarlo. ¡Muy apreciado! ❤️ Con suerte, la solución en graceful-fs es la correcta y se publica.

@SimenB ¡De

¿Alguna idea de cuándo llegará esta solución a un lanzamiento?

@cpojer ¿ podría proporcionar más información sobre por qué está cerrado? ¿Se proporciona una solución? Todavía tenemos este problema

Disculpas, parece que la solución aún no ha llegado a graceful-fs :(

¿Pueden varias personas confirmar que el uso de https://github.com/isaacs/node-graceful-fs/pull/119 soluciona sus problemas?

Puede usar la bifurcación utilizando resoluciones de hilo, consulte https://yarnpkg.com/en/docs/selective-version-resolutions , que debería permitirle implementar la corrección en CI, etc.

p.ej

{
  "resolutions": {
    "graceful-fs": "mekwall/node-graceful-fs#a10aa576f771d7cf3dfaee523f2e02d6eb11a89f"
  }
}

@SimenB Me resuelve el problema, al menos 😄

+1 para mí también.

@SimenB También solucionó mi problema y ahora puedo usar jest 22 en Windows. (Estábamos atrapados en 20 antes de esto).

Editar: En realidad, funcionó en mi computadora portátil de desarrollo, pero no funcionó en el servidor de compilación. Sin embargo, está ejecutando yarn 1.2.1, ¿tal vez por eso?

[16:47:55][Step 5/8]     jest: failed to read cache file: D:/TeamCity/buildAgent2/temp/buildTmp/jest/jest-transform-cache-c39254d365b4bcb2c90f133d4b359d91-56a1804d8d831b3401a35a7e81857f3b/7e/rafPolyfill_7e7a83ed3f2680ba9aec0e45f59ade5d
[16:47:55][Step 5/8]     Failure message: EPERM: operation not permitted, open 'D:\TeamCity\buildAgent2\temp\buildTmp\jest\jest-transform-cache-c39254d365b4bcb2c90f133d4b359d91-56a1804d8d831b3401a35a7e81857f3b\7e\rafPolyfill_7e7a83ed3f2680ba9aec0e45f59ade5d'
[16:47:55][Step 5/8]       
[16:47:55][Step 5/8]       at readCacheFile (node_modules/jest-runtime/build/script_transformer.js:465:60)

Yarn 1.0.0 debería ser suficiente, aunque vale la pena intentar actualizarlo

Intenté poner la resolución, pero todavía me falla. Sin embargo, tengo infracciones de ENOENT y EPERM:

    jest: failed to read cache file: C:/Users/dev/AppData/Local/Temp/jest/jest-transform-cache-857f905b2da01d52a9d1d17b6772ea4a-3a91587e29d4fef23c6e0cf16b2f5679/7d/index_7d0afc82f0b29ec31c4b5f296cbdee74
    Failure message: ENOENT: no such file or directory, open 'C:\Users\dev\AppData\Local\Temp\jest\jest-transform-cache-857f905b2da01d52a9d1d17b6772ea4a-3a91587e29d4fef23c6e0cf16b2f5679\7d\index_7d0afc82f0b29ec31c4b5f296cbdee74'

      at Object.fs.openSync (../fs.js:653:18)
      at Object.fs.readFileSync (../fs.js:554:33)

y

    jest: failed to read cache file: C:/Users/dev/AppData/Local/Temp/jest/jest-transform-cache-857f905b2da01d52a9d1d17b6772ea4a-3a91587e29d4fef23c6e0cf16b2f5679/c4/std_pb_c403e6e7645c904896b66f44a3e43606
    Failure message: EPERM: operation not permitted, open 'C:\Users\dev\AppData\Local\Temp\jest\jest-transform-cache-857f905b2da01d52a9d1d17b6772ea4a-3a91587e29d4fef23c6e0cf16b2f5679\c4\std_pb_c403e6e7645c904896b66f44a3e43606'

      at Object.fs.openSync (../fs.js:653:18)
      at Object.fs.readFileSync (../fs.js:554:33)

@mreishus ¿Su servidor de compilación ejecuta Windows? Debido a que las correcciones en graceful-fs solo apuntarán a Windows, pero no debería suceder en un sistema operativo basado en Linux.

@mekwall sí, Windows, pero es Windows Server 2012 R2

Este es un problema importante para mí y no ha pasado nada con graceful-fs desde noviembre de 2016 de lo que puedo ver. Así que me estoy volviendo bastante pesimista de que la solución que proporcionó -i y la solución alternativa?

¿--RunInBand no funciona para usted @frenic?

Eso es lo mismo que -i y sí, funciona. Pero, lamentablemente, no es sostenible a largo plazo para proyectos más grandes.

Supongo que podríamos bifurcar y publicar el nuestro, pero no parece que la solución funcione para todos.

Estoy en la misma situación, pero en mi caso, --runInBand no funciona.

Revisé la anulación de graceful-fs con la última versión de Jest y, desafortunadamente, ya no parece funcionar de manera tan confiable desde la última vez que la probé. Todavía existe una posibilidad distinta de cero de que se encuentre en una condición de carrera en grandes conjuntos de pruebas.

Después de desplazarme por este hilo, encontré una resolución usando yarn . ¿Existe una resolución que utilice npm lugar?

Hemos tenido bastante buena suerte hasta ahora con solo agregar la versión parcheada de graceful-fs a nuestro package.json. Trabaja para nosotros con npm e hilo.

"graceful-fs": "https://github.com/mekwall/node-graceful-fs.git#patch-1",

Hola,

Por alguna razón, solo obtenemos este error cuando se ejecuta desde Jenkins, no cuando se ejecuta localmente (incluso en la misma máquina / carpeta, etc.)
La solución de @jsheetzati también nos funciona (usando npm), pero es un parche después de todo. ¿Existe una ETA para resolver esto de forma permanente?

Gracias,
Mor

También tenemos este problema al ejecutar jest desde Jenkins. --runInBand opción
Como solución temporal, utilizamos el complemento de recursos bloqueables para asegurarnos de que solo se ejecute jest proceso --runInBand .
Espero que este comentario sea útil para alguien.

@nyrkovalex Lo que hacemos para evitar el problema que está describiendo es usar la opción de directorio de caché de Jest para asegurarnos de que la caché no se comparta entre los espacios de trabajo.

Lo hacemos publicando un preset de Jest que establece cacheDirectory: '<rootDir>/.jest-cache' y asegurándonos de que todos los paquetes lo usen. Si lo hace, asegúrese de agregar .jest-cache a .gitignore .

Antes de agregar esa opción, tendríamos varios problemas como resultado de tener un caché Jest global compartido entre 16 ejecutores por agente de Jenkins. El uso de recursos bloqueables también evitará los problemas como mencionó, pero es un desperdicio ya que no está utilizando su agente de Jenkins en todo su potencial (ya que las pruebas de Jest se convierten en un cuello de botella).

@ anescobar1991 Esa opción es definitivamente una mejor solución, consideraremos usarla.
¡Gracias por un consejo!

Hola,

usamos gradle para ejecutar npm (no preguntes por qué :)) y la combinación de eso con Jenkins es increíble.
Nosotros tratamos:

1. configurar el caché para que esté en el directorio local en lugar del caché global
2. usando --runInBand
3. solo se ejecuta un único trabajo en el agente, no hay trabajos paralelos
4. ejecutar la prueba gradle --max-workers 1 (y no usar --parallel)

Todos fallan con el mismo error.
La única solución que nos funciona es la de @jsheetzati ; desearía que esto se solucionara formalmente.

Probablemente podríamos bifurcar y publicar con esa solución.

que sería increíble...

Tengo mucho este problema y el parche para elegantes fs funcionó para mí. Así que agradecería esta solución.

Como solución alternativa para jugar con graceful-fs, ¿no podría simplemente darle a cada proceso / hilo de trabajo su propio directorio de caché para evitar la condición de carrera?

Probablemente sea lento, pero tenemos que usar --runInBand en nuestro servidor CI y eso es mucho peor.

Si alguien me puede señalar los archivos correctos para mirar, incluso podría intentar escribir un parche. Me cuesta mucho navegar por la fuente de la broma.

No estoy seguro de qué es, pero han pasado algunas semanas, posiblemente un par de meses y ya no he observado la falla. Hemos estado usando jest 22.4.2 durante un tiempo y recientemente lo actualizamos a 22.4.4. También hemos actualizado varios otros paquetes.

solo para agregar, estoy viendo esto con broma 23.6 en un servidor de CI de Windows Jenkins.

• --runInBand funciona, pero duplica el tiempo de prueba, por lo que no es genial, y dado que tenemos pruebas ejecutadas antes de la publicación, no puedo habilitar esto sin entristecer a los miembros de mi equipo.
• la anulación de graceful-fs en package.json , como lo menciona @jsheetzati (https://github.com/facebook/jest/issues/4444#issuecomment-370533355) funciona, pero es un truco.

Dado que graceful-fs no está haciendo mucho al respecto (https://github.com/isaacs/node-graceful-fs/pull/131 no ha visto acción desde julio del año pasado), tal vez sea hora de bifurcar ? Agregué un comentario molesto allí, pero no espero que eso haga que alguien de repente salte a resolver esto) ':

Tengo el mismo problema pero el mensaje de error es diferente
Failure message: EBADF: bad file descriptor, close

jest: failed to cache transform results in: C:/agent/_work/_temp/jest/jest-transform-cache-2a12bf9796741cb06fb97a276aa09712-7d718cda2d798ae78eb741b3feff799e/7b/test-setup_7bdb1937d8dbbf5088142bc21e74a530
2019-01-24T13:44:55.5496091Z     Failure message: EBADF: bad file descriptor, close

Parece que ejecutar jest con --runInBand no resuelve el problema la primera vez, pero solo después de otra ejecución se ejecuta sin errores.

Se ejecuta en Windows 10 Enterprise VM como parte de una compilación de TFS.

@EthanSankin, ¿puedes probar con el

Estoy trabajando en un reemplazo para graceful-fs que debería resolver estos problemas. Actualmente está en alfa, pero sería genial tener algunos de los primeros en adoptarlo: https://github.com/mekwall/normalized-fs

Revertir a la versión anterior de write-file-atomic resolvió el problema.

@moizgh ¿de qué versión a qué versión?

@moizgh ¿de qué versión a qué versión?

2.4.2 hasta 2.3.0

@iarna parece que se introdujo una regresión.

También se encuentra con este problema, ¿alguna idea sobre una solución mejor / permanente?

Esto comenzó de nuevo para nosotros en los últimos meses, ventanas, muy intermitentes.

write-file-atomic ya no usa graceful-fs, ¿tal vez eso tenga algo que ver con eso?