стек 2.7.1: сбой сборки из-за занятости ресурса (занят текстовый файл) в Ubuntu

#haskell #haskell-stack

Вопрос:

Я не могу выполнить stack build какие — либо проекты в Ubuntu 20.04 или 18.04, работающие в качестве гостя VirtualBox в Windows 10. Построение завершается неудачно при попытке переименовать временный файл: .stack-cabal-mod11115-0.tmp: rename: resource busy (Text file busy)

изменить: похоже, это происходит только в общих папках VirtualBox. Стек может успешно создать проект в папке, которая не является общей для Windows.

Ранее у меня не было проблем с версиями стека 1.9.x в идентичных средах. На данный момент я даже не могу получить сборку стека для компиляции нового проекта при чистой установке Ubuntu. Если я понижу рейтинг до 1.9.3, все волшебным образом сработает. Я удалил ~.stack и .рабочие папки стека и повторил попытку без успеха.

Ниже приведены результаты использования нового проекта stack new . Я могу использовать stack repl , хотя я все еще получаю сообщение об ошибке о сбое сборки с

 vagrant@ubuntu-focal:/vagrant/test$ stack --version
Version 2.7.1, Git revision 8afe0c2932716b0441cf4440d6942c59568b6b19 x86_64 hpack-0.34.4
vagrant@ubuntu-focal:/vagrant/test$ stack setup
Preparing to install GHC (tinfo6) to an isolated location.
This will not interfere with any system-level installation.
Downloaded ghc-tinfo6-8.10.4.
Installed GHC.
stack will use a sandboxed GHC it installed
For more information on paths, see 'stack path' and 'stack exec env'
To use this GHC and packages outside of a project, consider using:
stack ghc, stack ghci, stack runghc, or stack exec

vagrant@ubuntu-focal:/vagrant/test$ stack build
[1 of 2] Compiling Main             ( /home/vagrant/.stack/setup-exe-src/setup-mPHDZzAJ.hs, /home/vagrant/.stack/setup-exe-src/setup-mPHDZzAJ.o )
[2 of 2] Compiling StackSetupShim   ( /home/vagrant/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /home/vagrant/.stack/setup-exe-src/setup-shim-mPHDZzAJ.o )
Linking /home/vagrant/.stack/setup-exe-cache/x86_64-linux-tinfo6/tmp-Cabal-simple_mPHDZzAJ_3.2.1.0_ghc-8.10.4 ...
Building all executables for `test' once. After a successful build of all of them, only specified executables will be rebuilt.
test> configure (lib   exe)
Configuring test-0.1.0.0...
/vagrant/test/.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.2.1.0/.stack-cabal-mod11009-2.tmp: rename: resource busy (Text file                 busy)

vagrant@ubuntu-focal:/vagrant/test$ stack build
Building all executables for `test' once. After a successful build of all of them, only specified executables will be rebuilt.
test> configure (lib   exe)
Configuring test-0.1.0.0...
/vagrant/test/.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.2.1.0/.stack-cabal-mod11115-0.tmp: rename: resource busy (Text file busy)
 

Спасибо.

Комментарии:

1. Я просто попытался воспроизвести вашу проблему в ubuntu:focal изображении Докера, но это сработало для меня. Вот что я запустил: apt-get update; apt-get -y install curl; curl -sSL https://get.haskellstack.org/ | sh; stack new test; cd test; stack setup; stack build можете ли вы посмотреть, сможете ли вы воспроизвести проблему там с помощью этих точных команд?

2. Спасибо Джозефу — интересно, что это работает, если я создаю проект в своем домашнем каталоге, но если я создаю проект в папке virtualbox, которая является общей для Windows, я сталкиваюсь с ошибкой. Так что, скорее всего, это проблема с virtualbox, а не проблема со стеком; хотя я не знаю, почему проблема проявляется в версиях стека 2.*, а не 1.9.*. Я попробовал несколько вещей с VirtualBox, например, понизил рейтинг гостевых дополнений, но безрезультатно — я продолжу искать, хотя.

3. Тот факт, что он разбивается только в общих папках VirtualBox, действительно важен — пожалуйста, отредактируйте эту деталь в вопросе.

4. «Переименование завершается неудачно, потому что oldpath или newpath-это каталог, который используется каким-либо процессом (возможно, как текущий рабочий каталог или как корневой каталог, или потому, что он был открыт для чтения) или используется системой (например, как точка монтирования), в то время как система считает это ошибкой». Это действительно помогло бы, если бы вы могли выяснить, что такое старый путь и новый путь. Можете ли вы переименовать подкаталоги в общей папке?

5. Да, у меня нет проблем с переименованием подкаталогов и файлов bash в общей папке. Проблема существует только через стек. И только с версиями больше 1.9.x для меня.