Jest: условие гонки записи в кэш между процессами

Это не связано? https://github.com/facebook/jest/pull/4432

Я так не верю. Я считаю, что случай, который мы видим в нашем репо, - это тот же самый файл, который имитируется для двух разных процессов (при параллельной работе), что приводит к сбою операции записи в кеш, потому что один процесс заблокировал файл. Этот билет больше похож на разные файлы с одинаковым содержимым. В наших репозиториях нет ни одного из тех случаев, когда мы столкнулись с этой проблемой.

В основном мы сталкиваемся с той же проблемой с нашими тестами. Одним из простых способов воспроизведения было удаление шутки cacheDirectory чтобы принудительно создать кеш при следующем запуске.
`` Не удалось запустить набор тестов

jest: failed to cache transform results in:

C: / myniceproject / src / jest-cache / jest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b / 3f / settingsProvider_3f1439e55275bd795ec
Сообщение об ошибке: EPERM: операция не разрешена, переименовать
'C: \ myniceproject \ srcjest-cachejest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b \ 3f \ settingsProvider_3f1439e55275d732795ecf'
->
'C: \ myniceproject \ srcjest-cachejest-transform-cache-b2e8f1f700b9bd266a0d27bb01b47a2b-34a7e3d71d38ff01f65fdb5abdf5126b \ 3f \ settingsProvider_3f1439e55275b32795ecfcf

Имеете ту же проблему и не можете найти способ ее обойти. Вот так шутка для нас в принципе непригодна.

Мы пытаемся выполнить обновление до 21.2.0 с 20.0.4, и теперь на наших серверах сборки возникает следующая ошибка:

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)

У меня сейчас такая же проблема, тесты ломаются случайным образом.

Если я запускаю тесты с флагом --runInBand, то, как и ожидалось, все в порядке.

Я довольно часто вижу одну и ту же проблему:

  ● 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)

шутка 21.2.1
узел 6.11.1
ОС Windows

--no-cache не помогает, а jest-transform-cache все еще пишется. Помогает только --runInBand , что для больших проектов вряд ли приемлемо.

Что мы можем сделать, чтобы помочь диагностировать проблему? Должен ли я создавать репродукционный футляр?

Это критическая ошибка? Можно ли рассматривать это как предупреждение, а не как удаление всего набора тестов? Есть ли способ отступить и повторить попытку?

Было бы здорово иметь небольшую репродукцию

Вот репродукция: https://github.com/asapach/jest-cache-issue/
Он эффективно запускает lodash-es через babel-jest для заполнения кеша преобразования.
У меня это не получается в 80% случаев на двух разных машинах (Win8.1 и Win10).
Если вы удалите --no-cache произойдет сбой в 100% случаев. Добавление --runInBand снижает его до 0%.

(Из любопытства попытался запустить его в WSL на Win10, и проблема не воспроизводится с помощью Posix API)

Это просто происходит в Windows? У меня нет доступа к машинам с Windows, кроме виртуальных машин, поэтому мне не так просто отлаживать ...

@jeanlauliac, вы добавили write-file-atomic в # 4088, не могли бы вы помочь?

Эта проблема очень похожа на https://github.com/npm/write-file-atomic/issues/10 и https://github.com/npm/write-file-atomic/pull/22.

Только что запустил трассировку

Время суток | Имя процесса | PID | Операция | Путь | Результат | Деталь
- | - | - | - | - | - | -
16: 54: 43.2304011 | node.exe | 7624 | SetRenameInformationFile | ... \ constant_ee286bbcf367680ce61a90e506522f92.82986661 | УСПЕХ | ReplaceIfExists: True, имя файла: ... \ constant_ee286bbcf367680ce61a90e506522f92
16: 54: 43.2305499 | node.exe | 8208 | SetRenameInformationFile | ... \ constant_ee286bbcf367680ce61a90e506522f92.103872574 | В ДОСТУПЕ ЗАПРЕЩЕНО | ReplaceIfExists: True, имя файла: ... \ constant_ee286bbcf367680ce61a90e506522f92

Как видите, два процесса пытаются переименовать один и тот же файл с интервалом в 1 мс друг от друга, и второй процесс не работает.

Я думаю, что npm / write-file-atomic # 22 обращается к асинхронной версии writeFile() , но writeFileSync() все еще затронут.

Можно ли было бы создать репро, показывающее, что простое использование write-file-atomic в worker-farm как-то не работает? Было бы здорово открыть вопрос против этого проекта, поскольку я думаю, что исправление должно быть именно здесь.

Или, если бы вы могли написать тест в шутке, который показывает ту же ошибку (у нас есть CI приложения), это тоже могло бы стать началом?

Я даже не уверен, какое поведение мы хотим в случае этой ошибки. Повторить запись? Повторить тест? Весь тестовый файл?

ОК, попробую создать еще репро. Не уверен, что можно создать тест-шутку, потому что для этого потребуется запустить несколько процессов, отключить / очистить кеш и продолжать работу, пока он не выйдет из строя.

Я даже не уверен, какое поведение мы хотим в случае этой ошибки.

Ну, во-первых, проблема не должна возникать даже при включенном --no-cache , поскольку кеш не должен заполняться.
Во-вторых, я не уверен, что можно правильно повторить операцию синхронизации - можно ли использовать writeFile() вместо writeFileSync() ? Таким образом, write-file-atomic должен повторить попытку автоматически (я создам тест для подтверждения).

Ну, во-первых, проблема не должна возникать даже при включенном --no-cache , поскольку кеш не должен заполняться.

Это хороший момент, и его следует исправить отдельно. Таким образом, --no-cache может, по крайней мере, быть обходным решением.

Во-вторых, я не уверен, что можно правильно повторить операцию синхронизации - можно ли использовать writeFile() вместо writeFileSync() ?

@cpojer мысли о том, как сделать так, чтобы он не синхронизировался? Не уверен, как это масштабируется. Или, если у вас есть другая идея, как это исправить

• --no-cache --reset-cache самом деле больше похоже на
• Эти операции должны быть синхронизированы, потому что они происходят во время вызовов require в пользовательском коде, поэтому мы не можем это изменить.

Вот другой пример с worker-farm и write-file-atomic : https://github.com/asapach/write-atomic-issue

На данный момент результаты: версия с синхронизацией не работает, как и ожидалось, но, что удивительно, также не работает асинхронная версия. Это означает, что они, вероятно, реализуют очередь повторных попыток только тогда, когда она выполняется в том же процессе, что в нашем случае не помогает.

Я бы хотел сохранить это.

Новый флаг? Это имя вводит в заблуждение. И, например, на CI вам редко нужен кеш, так что это просто напрасная трата ресурсов. Или кеш, сгенерированный за один тестовый прогон, используется во время --no-cache , и игнорирует только существующие кеши?

Вот другой репродукт с worker-farm и write-file-atomic

Потрясающе! Не могли бы вы поднять вопрос против атомарной записи в файл? Кажется, что исправление должно быть там, а если нет (они не хотят поддерживать одновременную запись нескольких процессов), мы можем вернуться к нам. WDYT?

Патч, который я пробовал локально, который, казалось, работал, игнорирует ошибку, если она возникает из-за попытки переименовать файл с тем же содержимым. Поскольку это просто означает, что в гонке «выиграл» другой процесс, мы можем проигнорировать его и двигаться дальше.

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 , конечно, запишу вопрос.

@cpojer , можно ли проглотить / проигнорировать эту ошибку и рассматривать как предупреждение? Это означает, что файл уже был записан и никакие данные не должны быть потеряны.

Проблема с апстримом: npm / write-file-atomic # 28

Я думаю, это означает, что «переименование» не является атомарной операцией в Windows, поэтому оно нарушает предположение, сделанное write-file-atomic . Если нет флага, который можно было бы включить на уровне Windows API, это может означать, что вообще невозможно иметь атомарные записи / переименования в Windows.

@jwbay мне indexOf я бы использовал e.code === 'EPERM' (более надежный, не зависит от конкретного сообщения). Я не думаю, что нам следует читать файл снова, чтобы проверить значение, потому что это может вызвать дополнительные проблемы с параллелизмом (например, если файл записывается еще одним процессом в то же время). Не могли бы вы прислать PR, пожалуйста?

Я собирался начать работу над PR для write-file-atomic в соответствии со строками «если нас просят написать синхронизацию файла, но он уже находится в очереди на асинхронную запись, выход» (возможно, с опцией чтобы включить поведение). Но если мы будем счастливы справиться с этим на уровне Jest, я не буду торопиться. cc @jeanlauliac

Я собирался начать работу над PR для записи-файла-атомарной в соответствии со строками «если нас просят написать синхронизацию файлов, но она уже находится в очереди на асинхронную запись, выход» (возможно, с возможностью включите поведение).

Я думаю, что добавление этой логики (локальной очереди) не решит проблему, потому что чаще всего это происходит, когда разные процессы пытаются записать (переименовать) в один и тот же файл.

Чтобы исправить проблемы параллелизма раз и навсегда, нам, возможно, придется пересмотреть то, как мы выполняем кеширование, например, иметь один процесс, который обращается к кешу, с которым мы общаемся через какой-то IPC. Существующие системы хранения ключей / значений могут быть удобными, например memcached .

Я думаю, что добавление этой логики (локальной очереди) не решит проблему, потому что чаще всего это происходит, когда разные процессы пытаются записать (переименовать) в один и тот же файл.

Ах, возможно, я тогда неправильно понял проблему. Как я это читал, в библиотеке уже есть механизм очередей, который хорошо работает для асинхронных запросов, но если вы смешиваете синхронизирующие запросы _ также _, вы можете получить коллизии.

Мой вышеупомянутый запрос на перенос должен решить эту проблему. По крайней мере, это помогло мне!

@mekwall , я думаю, они используют rename() в асинхронной версии writeFile() , но в моем тесте он все еще не работает: https://github.com/asapach/write-atomic-issue. Не могли бы вы попробовать запустить мое воспроизведение? Я думаю, что ваше изменение может минимизировать вероятность возникновения этой проблемы, но не устраняет ее полностью.

@asapach Вы пробовали мои изменения? Потому что я пробовал несколько раз и никогда не получал EPERM: operation not permitted, rename с моими изменениями, получая каждый раз без него.

@mekwall , да, все еще не

Вернее, технически это не дает сбоя (потому что поток синхронизации не прерывается), но консоль все еще завалена ошибками EPERM.

@asapach Я обнаружил, в чем проблема. Он находится в полифилле graceful-fs . Я опубликовал исправление в этом PR: https://github.com/isaacs/node-graceful-fs/pull/119

@mekwall , да, похоже, это решает проблему - больше никаких ошибок как в синхронных, так и в асинхронных версиях.
Проблема в том, что временные файлы не удаляются, потому что fs.unlinkSync(tmpfile) никогда не вызывается: https://github.com/npm/write-file-atomic/pull/29/files#diff -168726dbe96b3ce427e7fedce31bb0bcR198

@asapach Я добавил отсоединение от graceful-fs rename, но я не уверен, что это правильный путь. Afaik fs.rename использует функцию MoveFile, и она не должна копировать источник в место назначения. Источник должен просто изменить имя, а источник и место назначения никогда не должны существовать одновременно.

@mekwall , это немного помогает, но в некоторых случаях, если воркер прерывается раньше (потому что вся работа сделана), некоторые файлы не очищаются, так как он не ждет очистки. Асинхронная версия работает нормально.

@asapach Это совсем не работает, как ожидалось. Мне нужно погрузиться во внутренности узла, чтобы понять, как он на самом деле работает и каким должно быть предполагаемое поведение. Я считаю, что весь смысл graceful-fs в том, чтобы он работал одинаково на каждой платформе, поэтому я углублюсь в это. По крайней мере, мы нашли виновника :)

@asapach Я понял, что мой PR для write-file-atomic не сработает, поэтому я использовал другой подход, добавив fs.renameSync в graceful-fs с теми же обходными путями, что и fs.rename но блокировка. Благодаря этому ваш тест будет работать так, как ожидалось!

@mekwall , спасибо, я проверил ваши изменения на обоих моих репро случаях, и ни один из них не
Я думаю, что с другой стороны, я вижу увеличение использования ЦП и диска для синхронизации, но это, вероятно, ожидаемо.

Спасибо большое за то, что подобрали это и помогли исправить. Очень признателен! ❤️ Надеюсь, исправление в graceful-fs правильное, и оно будет выпущено.

@SimenB Добро пожаловать! Нам это очень больно на работе, поэтому у меня есть время, чтобы разобраться с этим моей командой. Изменения коснутся многих пакетов, поэтому, скорее всего, им потребуется время, чтобы их принять: /

Есть идеи, когда это обходное решение дойдет до релиза?

@cpojer не могли бы вы предоставить дополнительную информацию, почему он закрыт? есть ли исправление? У нас все еще есть эта проблема

Извините, похоже, что исправление еще не попало в graceful-fs :(

Могут ли несколько человек подтвердить, что использование https://github.com/isaacs/node-graceful-fs/pull/119 решает их проблемы?

Вы можете использовать вилку, используя разрешения пряжи, см. Https://yarnpkg.com/en/docs/selective-version-resolutions , что должно позволить вам развернуть исправление для CI и т. Д.

например

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

@SimenB Это решает проблему для меня, по крайней мере 😄

+1 Для меня тоже.

@SimenB Также исправлена ​​моя проблема, и теперь я могу использовать jest 22 в Windows. (До этого мы застряли на 20).

Изменить: на самом деле он работал на моем ноутбуке разработчика, но не работал на сервере сборки. Хотя там работает пряжа 1.2.1, может поэтому?

[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 должно быть достаточно, тем не менее, стоит попробовать обновить

Просто попытался вставить разрешение, но у меня все еще не получается. Однако у меня есть нарушения как ENOENT, так и 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)

и

    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 На вашем сервере сборки работает Windows? Поскольку исправления в graceful-fs будут нацелены только на Windows, но этого не должно происходить в ОС на базе Linux.

@mekwall да, windows - но это windows server 2012 R2

Это серьезная проблема для меня, и с ноября 2016 года с graceful-fs ничего не произошло из того, что я вижу. Поэтому я становлюсь весьма пессимистичным, что исправление, предоставленное @mekwall , не будет объединено в ближайшее время. Есть ли какое-либо временное решение, которое мы можем использовать, кроме флага -i и обходного пути разрешения?

--RunInBand не работает для вас @frenic?

Это то же самое, что и -i и да, это работает. Но, к сожалению, в долгосрочной перспективе для более крупных проектов это неприемлемо.

Думаю, мы могли бы форкнуть и опубликовать свои собственные, но не похоже, что исправление подойдет всем.

У меня такая же ситуация, но в моем случае --runInBand не работает.

Я проверил переопределение graceful-fs с помощью последней версии Jest, и, к сожалению, оно перестало работать так надежно с тех пор, как я последний раз тестировал его. По-прежнему существует ненулевой шанс, что он попадет в состояние гонки на больших тестовых наборах.

После прокрутки этой темы я нашел разрешение с помощью yarn . Есть ли разрешение, использующее вместо этого npm ?

Пока что нам очень повезло, просто добавив исправленную версию graceful-fs в наш package.json. У нас работает с npm и пряжей.

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

Привет,

По какой-то причине мы получаем эту ошибку только при запуске из Jenkins, а не при локальном запуске (даже на той же машине / папке и т. Д.)
Решение @jsheetzati тоже работает для нас (с использованием npm), но в конце концов это патч. Есть ли расчетное время прибытия для окончательного решения этой проблемы?

Благодаря,
Мор

У нас также есть эта проблема при запуске jest от Jenkins. --runInBand помогает избежать сбоев при выполнении одного задания, но при параллельном запуске нескольких сборок jest все равно не удается.
В качестве обходного пути мы используем плагин блокируемых ресурсов, чтобы гарантировать, что только один процесс jest выполняется одновременно с сохранением параметра --runInBand .
Надеюсь, этот комментарий будет кому-то полезен.

@nyrkovalex Чтобы избежать проблемы, которую вы описываете, мы используем опцию каталога кэша Jest, чтобы гарантировать, что кеш не используется в разных рабочих областях.

Мы делаем это, публикуя пресет Jest, который устанавливает cacheDirectory: '<rootDir>/.jest-cache' и проверяем, что все пакеты его используют. В этом случае не забудьте добавить .jest-cache к .gitignore .

Прежде чем добавить эту опцию, мы столкнемся с несколькими проблемами из-за того, что глобальный кеш Jest будет совместно использоваться 16 исполнителями для каждого агента Jenkins. Использование блокируемых ресурсов также предотвратит проблемы, о которых вы упомянули, но является расточительным, поскольку вы не используете свой агент Jenkins в полной мере (поскольку тесты Jest становятся узким местом).

@ anescobar1991 Этот вариант - определенно лучшее решение, мы рассмотрим его использование.
Спасибо за подсказку!

Привет,

мы используем gradle для запуска npm (не спрашивайте почему :)), и сочетание этого с Jenkins - убийца.
Мы старались:

1. установка кеша в локальный каталог вместо глобального кеша
2. используя --runInBand
3. на агенте выполняется только одно задание - параллельных заданий нет
4. запуск теста Gradle --max-worker 1 (и без использования --parallel)

Все терпят неудачу с одной и той же ошибкой.
Единственное решение, которое работает для нас, - это решение от @jsheetzati - я бы хотел, чтобы это было официально исправлено.

Мы могли бы, вероятно, выполнить форк и опубликовать это исправление

это было бы круто...

У меня эта проблема часто возникает, и патч для изящной fs у меня сработал. Так что я был бы признателен за это исправление.

Не могли бы вы просто дать каждому рабочему процессу / потоку собственный каталог кеша, чтобы избежать состояния гонки?

Вероятно, это медленно, но мы должны использовать --runInBand на нашем сервере CI, и это намного хуже.

Если кто-то может указать мне на нужные файлы, я могу даже попытаться написать патч. Мне очень сложно ориентироваться в источнике шутки.

Я не уверен, что это такое, но прошло несколько недель, возможно, пару месяцев, и я больше не наблюдал сбоев. Некоторое время мы использовали jest 22.4.2 и недавно обновились до 22.4.4. Мы также обновили различные другие пакеты.

просто чтобы врезаться - я вижу это с jest 23.6 на сервере Windows Jenkins CI.

• --runInBand действительно работает, но удваивает время тестирования, так что это не очень хорошо, и поскольку у нас есть тесты, запускаемые до push, я не могу включить это, не расстроив членов моей команды
• переопределение graceful-fs в package.json , как упомянуто @jsheetzati (https://github.com/facebook/jest/issues/4444#issuecomment-370533355), работает, но это своего рода взлом.

Поскольку graceful-fs мало что делает с этим (https://github.com/isaacs/node-graceful-fs/pull/131 не видел действий с июля прошлого года), возможно, пора разветвляться ? Я добавил там ворчащий комментарий, но не ожидаю, что кто-то внезапно бросится разбираться с этим) ':

У меня такая же проблема, но сообщение об ошибке другое
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

Кажется, что запуск jest с --runInBand не решает проблему с первого раза, а только после следующего запуска выполняется без ошибок.

Работает на виртуальной машине Windows 10 Enterprise как часть сборки TFS.

@EthanSankin, можете ли вы также протестировать связанный PR graceful-fs?

Я работаю над заменой graceful-fs которая должна решить эти проблемы. В настоящее время он находится на стадии альфа-тестирования, но было бы здорово получить первых последователей: https://github.com/mekwall/normalized-fs

возврат к более старой версии write-file-atomic решил проблему.

@moizgh с какой версии на какую версию?

@moizgh с какой версии на какую версию?

2.4.2–2.3.0

@iarna похоже, что была введена регрессия.

Также сталкиваетесь с этой проблемой, есть ли какие-либо идеи относительно лучшего / постоянного исправления?

Это началось снова для нас в последние пару месяцев - окна - очень прерывистые.

write-file-atomic больше не использует graceful-fs - может, это как-то связано с этим?