Не удалось открыть файл
Обновлено: 06.07.2024
Автопредложение помогает быстро сузить результаты поиска, предлагая возможные совпадения по мере ввода.
Соня_Бауэрнфейнд
- Отметить как новое
- Добавить в закладки
- Подписаться
- Отключить звук
- Отправить сообщение другу
Перезагрузка из файлов QVD не удалась в Qlik Sense от апреля 2020 г. или более поздней версии и QlikView 12.50 с системной ошибкой: не удалось открыть файл в режиме записи для файла: \\имя_сервера\имя_папки\XXX.qvd
Другие симптомы могут включать:
<УЛ>Решение:
Поведение было скорректировано в:
<УЛ>Временное решение вручную:
Реализуйте следующий параметр ini EnableQvdAsyncWrite=0 .
Действия для Qlik Sense:
<УЛ>- Убедитесь, что нажата клавиша Enter/Return, чтобы создать новую пустую строку после последней настройки.
- Сохранить файл
- После внесения этих изменений на всех узлах запустите службы Qlik Sense Engine и Qlik Sense Service Dispatcher на каждом узле.
Действия для QlikView:
<УЛ>- Убедитесь, что запись введена в разделе [Настройки 7], а не в разделе [Аутентификация] (если введена в разделе [Аутентификация], запись не будет прочитана QVS)
- Сохранить файл
- Эти изменения были внесены на все узлы, выполняющие перезагрузку.
- Запустите службы распространения
Причина:
В выпуске Qlik Sense Enterprise для Windows от апреля 2020 г. и более поздних версиях, а также в QlikView 12.50 реализована оптимизация записи QVD, которая дает заметный прирост производительности, но на некоторых системах может привести к зависанию заданий перезагрузки. Причина зависания перезагрузки напрямую связана не с самой оптимизацией, а с новой скоростью записи.
При попытке запустить файл SQL с помощью программы командной строки mysql может появиться сообщение об ошибке Не удалось открыть файл, ошибка 2 .
В следующем примере делается попытка запустить исходную команду и выполнить файл query.sql:
Ошибка кода 2 означает, что MySQL не может найти файл .sql, который вы хотите выполнить.
Чтобы устранить эту ошибку, необходимо указать абсолютный путь к местоположению вашего файла.
Вы можете узнать абсолютный путь к вашему файлу, открыв терминал в каталоге или папке, где находится ваш файл SQL, и запустив команду pwd.
Например, вот абсолютный путь к каталогу, в котором я сохраняю файл query.sql:
Теперь мне просто нужно добавить путь к файлу, когда я ввожу исходную команду:
Обратите внимание, что вам нужно использовать косую черту ( / ) для разделения разделов пути. Использование обратной косой черты ( \ ) может вызвать ту же ошибку.
Вот пример:
Несмотря на то, что путь правильный, MySQL ожидает путь в стиле Unix с косой чертой.
Теперь вы сможете выполнить файл SQL. Есть и другие причины ошибки 2 в MySQL, поэтому давайте рассмотрим их далее.
Ошибка 2 из-за < или >символов
Еще одна причина, которая может вызвать ошибку, заключается в том, что вы добавляете символ больше чем > или меньше чем < перед путем к файлу, как показано ниже:
Символ больше или меньше обычно используется для вывода данных MySQL в файл SQL или выполнения скрипта из терминала без подключения к серверу MySQL.
Необходимо удалить символ, чтобы выполнить исходную команду без ошибок.
Ошибка 2 из-за точки с запятой при использовании \. команда
\. команда — это псевдоним исходной команды, которую можно использовать для запуска файла SQL.
Я не знаю, ошибка ли это в MySQL, но когда вы запускаете файл \.команда с точкой с запятой ; в конце пути к файлу вы получите сообщение об ошибке 2.
Взгляните на следующий пример:
Но такой же ошибки не произойдет, если вы используете исходную команду:
Чтобы решить эту проблему, вам нужно опустить точку с запятой, когда вы используете \. команда.
Таким образом вы исправите ошибку MySQL не удалось открыть файл 2.
Имейте в виду, что ошибка связана с тем, что MySQL не может найти файл, который вы хотите выполнить.
Возможно, вам нужно проверить путь, который вы передали в исходную команду, и посмотреть, нет ли опечатки, которая вызывает ошибку.
Статьи по теме:
Повысьте уровень своих навыков программирования
Я время от времени рассылаю электронные письма с последними руководствами по программированию. Оставьте свой адрес электронной почты в поле ниже, и я буду присылать новые материалы прямо на ваш почтовый ящик!
сообщить об этом объявлении
сообщить об этом объявлении
О нас
Натан Себхастян – инженер-программист, который любит писать технические руководства. Изучайте JavaScript и другие концепции технологий веб-разработки с помощью простых для понимания объяснений, написанных простым английским языком.
Когда я попытался найти определенный файл .sql, а именно файл "metropolises.sql", который я создал и сохранил ранее из базы данных, отображается следующая ошибка:
Не удалось открыть файл "metropolises.sql", ошибка: 2
Есть идеи, что пошло не так?
Я создал таблицу в базе данных. Теперь, чтобы получить созданные данные, я набрал SOURCE metropolises.sql; в терминал, однако появилось сообщение об ошибке, как описано выше. Почти уверен, что в созданной таблице нет ошибок.
26 ответов 26
Предполагая, что вы имеете в виду, что пытаетесь использовать исходную команду для выполнения операторов SQL из текстового файла, указанный номер ошибки, по-видимому, передается с уровня POSIX.
Поэтому, используя этот ресурс, мы можем сделать вывод, что значение ошибки 2 означает "нет такого файла или каталога".
Короче говоря, вы выбрали неверный путь.
Попробуйте указать абсолютный путь, так как неясно, каким будет текущий рабочий каталог в контексте вашего сервера MySQL. Вы можете предположить, что это рабочий каталог вашей оболочки, но не очевидно, что мы должны ожидать, что это правда.
Дополнительное примечание: не заключайте полный путь в кавычки. ИСТОЧНИК "/var/test.sql"; произойдет сбой с кодом ошибки 2, в то время как SOURCE /var/test.sql будет работать (при условии, что test.sql существует в этом месте).
Просто используйте абсолютный путь к файлу, а затем вместо обратной косой черты используйте прямую косую черту.
Пример:
с обратной косой чертой: исходный файл C:\folder1\metropolises.sql
с прямой косой чертой: исходный файл C:/folder1/metropolises.sql
Знаете ли вы, можно ли сохранить путь в глобальной или локальной переменной (например, @PATH_TO_THE_FILE) и использовать команду source, как в "source @PATH_TO_THE_FILE" (это не работает)? Спасибо.
мне не помогло. Показывает ту же ошибку, несмотря на изменение абсолютного пути с косой чертой. Есть предложения?
Обратите внимание, что если вы используете MySQL внутри докера, вы должны сначала скопировать дамп в свою среду докера MySQL. Для этого выполните следующие действия
Сначала проверьте и скопируйте идентификатор контейнера для докера MySQL, выполнив следующие действия:
Скопируйте файл дампа SQL в свой контейнер, используя:
sudo docker cp /path/to/sql/file.sql MysqlDockerID:/
Это скопирует файл дампа в корневую папку докера, если вы хотите скопировать файл в любой другой каталог/путь внутри докера, замените «/» после «MysqlDockerID:» на нужный вам путь.
Теперь для взаимодействия с MySQL внутри запущенного контейнера выполните следующую команду:
sudo docker exec -it MysqlDockerID bin/bash
Теперь подключитесь к MySQL с помощью терминала:
mysql -u имя_пользователя -p
Теперь вам будет предложено ввести пароль. Введите правильный пароль, чтобы продолжить.
Список доступных баз данных:
Появится список доступных баз данных
Предполагается, что именем вашей базы данных, в которую вы хотите импортировать дамп, является «MyDatabase». Переключитесь на это, используя:
Теперь вы можете импортировать файл, набрав:
Помните, что приведенная выше команда работает, если вы скопировали файл в корневую папку (используя шаг 2). Если вы скопировали его по любому другому пути, убедитесь, что вы используете тот же путь вместо этого
Автор:
Проблема:
При попытке открыть файл сцены, ранее открытый в 3ds Max, возникает одна из следующих ошибок, и файл не может быть открыт:
3ds Max
Ошибка открытия файла: \FileName.max
3ds Max
Ошибка утверждения!
Программа..
Сведения о том, как ваша программа может привести к ошибке утверждения, см. в документации Visual C++ по утверждениям.
Причины:
- Недопустимый путь к файлу или файл, открытый из временной папки.
Например, перемещение файла MAX (*.max) в новое место на жестком диске, а затем попытка открыть его снова с помощью параметра «Открыть недавние» приведет к ошибке «Открыть файл». Не удалось" ошибка. Это связано с тем, что 3ds Max запоминает предыдущий путь к файлу, где файл больше не находится.
- Плохая или недействительная ссылка на внешний ресурс, используемый файлом.
- Повреждение содержимого файла при сохранении. Это также может быть вызвано использованием функции «Сжатие при сохранении» в старых копиях 3ds Max для очень больших файлов.
- Файл сцены поврежден.
Решение:
Неверный путь к файлу или временной папке
Если ошибка возникает при использовании параметров быстрой ссылки «Открыть последние» в 3ds Max, снова откройте файл, используя вместо этого параметр «Открыть» ( Файл > Открыть ).
Ссылки или содержимое поврежденных ресурсов
- Измените расширение файла сцены на формат ZIP (*.zip).
- Откройте файл в утилите сжатия файлов, такой как 7zip, WinRAR или Winzip, чтобы просмотреть содержимое. Если результаты такие же, как показано ниже, велика вероятность, что большую часть содержимого удастся восстановить.
- Из результатов ZIP-архива перетащите часть ZIP-файла «Сцена» на рабочий стол Windows или в другое место на диске.
- Переименуйте файл в «Scene.max», затем попробуйте загрузить его снова непосредственно в 3ds Max.
Примечание. Если описанное выше не работает, попробуйте выполнить процедуру "Объединение поврежденных файлов". Объединение содержимого файла MAX с новой пустой сценой 3ds Max может позволить восстановить часть или все содержимое сцены.
Сжать при ошибке сохранения
Если описанные выше действия не помогли устранить ошибку, см. инструкции по устранению ошибок «Ошибка открытия файла» при использовании функции «Сжатие при сохранении» в 3ds Max.
тормоз работает нормально, пока не возникает следующая ошибка:
не удалось открыть файл /worka/work/username/BRAKER/braker/evidence_augustus.gff
Среда, 29 июля, 18:46:17 2020: запуск prothint.py
/scratch/gdleri1/ProtHint/bin/prothint.py --threads=1 --geneMarkGtf /worka/work/gdleri1/BRAKER/ Chicken/braker/GeneMark-ES/genemark.gtf /worka/work/gdleri1/BRAKER/chicken/br$
Среда, 29 июля, 19:19:18 2020: изменение источника подсказок в файлеvidence_augustus.gff с src=P на источник=M.
Я не понимаю, что происходит. полезны ли файлы gff, сгенерированные до сих пор?
Большое спасибо!
Текст был успешно обновлен, но возникли следующие ошибки:
glaudelrio прокомментировал 30 июля 2020 г.
Спасибо!
Ура!
glaudelrio прокомментировал 31 июля 2020 г.
Извините, что снова беспокою. но я последовал вашим советам и получил:
Не удалось выполнить /scratch/bin/prothint.py
Большое спасибо!
tomasbruna прокомментировал 3 августа 2020 г.
Я завершаю работу над обновленной версией BRAKER, в которой будут исправлены все эти проблемы.
tomasbruna прокомментировал 7 августа 2020 г.
пожалуйста, попробуйте загрузить последнюю версию BRAKER, все проблемы, связанные с ProtHint, должны быть исправлены. Я рекомендую запустить test2.sh в папке примеров.
glaudelrio прокомментировал 13 августа 2020 г.
Большое спасибо! Пробуем последнюю версию прямо сейчас! Я пытаюсь аннотировать геном птицы. Вы предлагаете фильтровать базу данных UniProt только для «позвоночных»? Поможет ли это оптимизировать время работы?
Большое спасибо!
tomasbruna прокомментировал 13 августа 2020 г.
Да, имеет смысл фильтровать базу данных только по позвоночным, маловероятно, что более отдаленные белки помогут, если позвоночных уже достаточно.
Вы также можете попробовать использовать белки из OrthoDB. Если он лучше охватывает белки птиц, он может работать лучше (но я не уверен, что это так прямо сейчас, вам нужно проверить). .
glaudelrio прокомментировал 14 августа 2020 г.
Привет, Томас! Я попытался запустить новейшую версию BRAKER с ProtHint 2.5, но снова программа прерывается, когда я добираюсь до ProtHint.
Не удалось выполнить /user/ProtHint-2.5.0/bin/prothint.py
tomasbruna прокомментировал 17 августа 2020 г.
приносим извинения за то, что проблема не устранена, давайте решим ее.
Вы получаете эту ошибку при запуске тестового примера (test2.sh) или только при вводе данных?
Вы можете поделиться полным журналом BRAKER?
glaudelrio прокомментировал 19 августа 2020 г.
Я попробую запустить тест. А пока вот файл журнала.
комментарий glaudelrio от 29 августа 2020 г.
Здравствуйте, у меня не работает тест. Я прилагаю файл ошибки для моей попытки запустить BRAKER. Большое спасибо за помощь!
tomasbruna прокомментировал 31 августа 2020 г.
из второго лог-файла (raker_e594427.txt) похоже, что проблема в следующем:
Попробуйте удалить круглые скобки (и другие подобные специальные символы) из входного файла белка.
тест мне не подходит.
Вы также пытались запустить тест с примерами входных данных (предоставленных в папке с примерами) или только со своими собственными?
glaudelrio прокомментировал 3 сентября 2020 г.
Привет! Я последовал вашим советам, и BRAKER работал дольше, чем когда-либо. ProtHint работал хорошо. Теперь он обнаружил новую ошибку, напечатанную в filterGenesIn_mRNAname.stderr:
синтаксическая ошибка в /worka/work/gdleri1/augustus-3.3.3/scripts/filterGenesIn_mRNAname.pl, строка 9, рядом с «Чрезмерно длинным оператором <> в /worka/work/gdleri1/augustus-3.3.3/scripts/ filterGenesIn_mRNAname.pl строка 20.
Вы знаете, о каком операторе идет речь?
Большое спасибо за терпение и помощь!
С наилучшими пожеланиями!
tomasbruna прокомментировал 4 сентября 2020 г.
попробуем отладить скрипт filterGenesIn_mRNAname.pl отдельно. Можете посмотреть вraker.log, последняя строка должна быть системным вызовом filterGenesIn_mRNAname.pl. Вы также можете поделиться файломraker.log здесь, он может содержать больше полезной информации
Совет: если ProtHint и GeneMark завершились успешно, вы можете позже передать их результаты в BRAKER с параметрами --geneMarkGtf и --hints (как показано здесь).
glaudelrio прокомментировал 11 сентября 2020 г.
Отлично! Мне удалось исправить эту проблему, скопировав исходную последовательность filterGenesIn_mRNAname.pl и изменив строку 20 с:
if ( $_ =~ m/transcript_id "(.*)"/ )
to
if ( $_ =~ m/transcript_id "([0-9_t]*)"/ )
Теперь у меня есть выходные файлы. С помощьюraker.gtf, а также augustus.hints.codingseq. теперь мне было интересно, что я должен сделать, чтобы перевести идентификаторы генов "g1", "g2", "g3" и т. д. в идентификаторы генов с возможностью поиска NCBI, ссылка Ensemble ENSG00000139083
Большое спасибо за всю помощь и терпение!
С наилучшими пожеланиями
tomasbruna прокомментировал 19 сентября 2020 г.
Рад, что вы смогли решить проблему. Можете ли вы на самом деле поделиться небольшим вводом, на котором исходный сценарий filterGenesIn_mRNAname.pl терпит неудачу? Я хотел бы взглянуть и, возможно, внедрить ваше исправление.
Что касается идентификаторов генов, BRAKER не предлагает никаких вариантов их изменения, вам придется использовать некоторые другие инструменты, такие как GenomeTools, для постобработки выходных файлов .gtf/.gff.
прокомментировал bbrunet 4 ноября 2020 г. •
У меня та же проблема, что и у исходной проблемы от 30 июля. Похоже, анализ с помощью ProtHint завершается нормально, но файл свидетельство_августуса.gff не создается:
[Вт, 3 ноября, 14:56:14 2020] ProtHint завершен.
ОШИБКА в файле /path/to/bin/BRAKER/scripts/braker.pl в строке 4982
не удалось открыть файл /path/to/braker/evidence_augustus.gff!
Последняя строка в файлеraker.log:
Вторник, 3 ноября, 14:56:14 2020: изменение источника подсказок вvidation_augustus.gff с src=P на src=M.
И в каталоге braker/errors не сообщается об ошибках, за исключением ошибки "in cleanup" в файле GeneMark-ES.stderr, которая, как я понимаю, не критична:
(in cleanup) (in cleanup) at /path/to/lib/site_perl/5.26.2/Object/InsideOut.pm строка 1953 во время глобального уничтожения.
Я работаю с версией 2.1.5 брейкера и 2.5.0 версии prothint, и мне удалось завершить анализ с их помощью без каких-либо проблем на отдельном геноме с данными как о РНКазе, так и о белке (конвейер D) (но не было также любой созданный здесь файл свидетельство_августуса.gff). Эта проблема связана с анализом с использованием только белков (конвейер C).
Я предположил, что отсутствующий в моем текущем анализе файл доказательства_августуса.gff не является проблемой для дальнейшего продвижения вперед, и просто перезапустил тормоз, используя файлы prothint.gff, доказательства.gff и prothing_augustus.gff, созданные при первом запуске, с параметрами: -prothint, --evidence и --hints соответственно. Правильно ли это, или должен быть входной файл доказательства_августуса.gff также для --hints?
В среду, 4 ноября 2020 г., в 17:42, bbrunet ***@***.***> написал: Здравствуйте, у меня та же проблема, что и в исходном выпуске от 30 июля, похоже на анализ с ProtHint. завершается нормально, но файл доказательства_августуса.gff не создается: [Вт, 3 ноября, 14:56:14 2020] ProtHint завершен. ОШИБКА в файле /path/to/bin/BRAKER/scripts/braker.pl в строке 4982 не удалось открыть файл /path/to/braker/evidence_augustus.gff! Последняя строка в файлеraker.log: вторник, 3 ноября, 14:56:14 2020: изменение источника подсказок в файлеvidence_augustus.gff с src=P на src=M. И в каталоге торможения/ошибок не сообщается об ошибках, за исключением ошибки «в очистке» в файле GeneMark-ES.stderr, которая, как я понимаю, не критична: (в очистке) (в очистке) в /path/to/lib/ site_perl/5.26.2/Object/InsideOut.pm строка 1953 во время глобального уничтожения. Я работаю с версией 2.1.5 брейкера и 2.5.0 протинта, и мне удалось завершить анализ с их помощью без каких-либо проблем на отдельном геноме с данными как о РНКазе, так и о белке (конвейер D) (но не было никаких доказательств_августус .файл gff, созданный здесь). Эта проблема относится к анализу с использованием только белков (конвейер C). Я предположил, что отсутствующий в моем текущем анализе файл доказательства_августуса.gff не является проблемой, и просто перезапустил тормоз, используя файлы prothint.gff, доказательства.gff и prothing_augustus.gff, созданные при первом запуске, с параметрами --prothint, --evidence и --hints соответственно. Правильно ли это, или должен быть входной файл файлаvide_augustus.gff для --hints? Спасибо, Брайан. Вы получили это, потому что подписаны на эту тему. Ответьте на это письмо напрямую, просмотрите его на GitHub или отмените подписку.
tomasbruna прокомментировал 13 ноября 2020 г.
эта проблема была решена в недавних коммитах, получите последний код из ветки master, как предложила Катарина.
Я предположил, что отсутствующий в моем текущем анализе файл свидетельство_августус.gff не является проблемой в дальнейшем, и просто перезапустил тормоз, используя файлы prothint.gff, доказательства.gff и prothing_augustus.gff, созданные при первом запуске с опции --prothint, --evidence и --hints соответственно. Правильно ли это, или должен быть входной файл доказательства_августуса.gff также для --hints?
Это все равно вызовет проблемы. В новейшей версии BRAKER удалены опции --prothint и --evidence, и теперь она работает только с файлом --hints prothint_augustus.gff, созданным ProtHint.
bbrunet прокомментировал 25 ноября 2020 г.
Здравствуйте, Катарина и Томас,
Приношу свои извинения за задержку с ответом, но мне потребовалось некоторое время, чтобы покопаться в этом подробнее и заставить все работать (я думаю). Я считаю, что теперь сделал это, используя следующую конфигурацию:
Я создал среду conda и установил пакет biocondaraker2 (v.2.1.5) (со всеми зависимостями, включая augustus v.3.3.3). Раньше я устанавливал GeneMarkES (с ProtHint) отдельно. Поскольку по какой-то причине я не мог выполнить прогоны в среде conda без ошибок, я удалил брекер2 из окружения с помощью --force, сохранив все его зависимости как есть, и установил последний коммит брекера2 (e215cb1< /tt>) путем клонирования с github. Я также попытался установить последнюю версию августуса, клонировав ее с github, используя все зависимости conda env, но я продолжал сталкиваться с проблемами при ее локальной установке. В любом случае, я просто использовал версию augustus в среде conda с парой обновленных сценариев augustus (например, filterGenesIn_mRNAname.pl (загружен 16 ноября) и getAnnoFastaFromJoingenes.py (загружен 17 ноября)).< /p>
Похоже, эта конфигурация работает, так как торможение 2 теперь завершается без ошибок (или, по крайней мере, важных). Я по-прежнему получаю сообщение об ошибке «в очистке» в файлах GeneMark-ES.stderr и GeneMark-ETP.stderr, а также предупреждения о загрузке в файле joingenes.stderr о том, что «начальные», «внутренние» и «терминальные» функции не ожидаются. .
Мне все еще нужно запустить getAnnoFastaFromJoingenes.py еще раз после завершения работы брекера, чтобы преобразовать файл braker.gtf в файлы .aa и .codingseq, как это было предложено в проблеме, зарегистрированной другим пользователем. Это приводит к странному формату имен в результирующих файлах (например, "file_1_file_1_g11438.t1"). Следует ли мне беспокоиться об этом?
Я могу опубликовать conda env и точные используемые команды, если это будет полезно?
tomasbruna прокомментировал 3 декабря 2020 г.
приносим извинения за сложные этапы установки, которые вам пришлось пройти. В последнее время было много разработок BRAKER2, мы подготовим новые выпуски, которые решат эти проблемы с установкой.
Я по-прежнему получаю ошибку "in cleanup" в файлах GeneMark-ES.stderr и GeneMark-ETP.stderr, а также предупреждения загрузки в файле joingenes.stderr об "initial", "internal" и " функции терминала не ожидаются.
Эти ошибки/предупреждения можно спокойно игнорировать. Спасибо, что сообщили о них, я постараюсь исправить их перед выпуском новой версии.
Мне все еще нужно снова запустить getAnnoFastaFromJoingenes.py после завершения работы брекера, чтобы преобразовать файл braker.gtf в файлы .aa и .codingseq, как было предложено в проблеме, зарегистрированной другим пользователем. Это приводит к странному формату имен в результирующих файлах (например, "file_1_file_1_g11438.t1"). Стоит ли мне беспокоиться об этом?
К сожалению, это нормально. В настоящее время мы работаем над лучшей интеграцией белков и данных RNA-Seq, что решит эту проблему.
Читайте также: