В Windows есть ошибки stat или stati64? - PullRequest
0 голосов
/ 02 ноября 2011

Я вижу странную проблему в моем проекте, когда Perl не может увидеть файл, хотя он присутствует на диске.Мы запускаем серию коротких серверных заданий (каждая с продолжительностью 10 с) через perl.Задание Backend записывает выходной файл и завершает работу, после чего процесс perl попытается передать его.Первоначально задание работает нормально, и внезапно не удается обнаружить файл, написанный бэкэндом.Отладка кода Perl (5.10.1 из http://www.cpan.org/src/), я обнаружил, что stati64 (win32_stat в win32.c) завершается с ошибкой и возвращает -1.При повторной попытке вызов работает нормально.Я могу гарантировать, что в бэкэнд-процессе нет условий гонки, так как мы пытаемся получить доступ к файлу в perl только после выхода из бэкэнда.

Кто-нибудь знает условия (при рекурсивном использовании в коротких заданиях), при которых stat (илиstati64) может сказать, что файл отсутствует, хотя файл существует в Windows?Кеширует ли результат предыдущего выполнения для оптимизации?

Ответы [ 3 ]

1 голос
/ 02 ноября 2011

Если вы можете воспроизвести проблему, используйте SysInternals Process Monitor (или устаревший, но более простой в использовании Filemon), чтобы увидеть, что происходит.

Одной из возможных причин является то, что какое-то другое приложение (например, антивирусная программа или механизм индексирования) заблокировало файл, но Procmon должен показать код ошибки из stat.

0 голосов
/ 21 мая 2012

Недавно я столкнулся с очень похожей проблемой при других обстоятельствах. При попытке получить доступ к файлу через CGI, _stati64() вернет -1 с ошибкой ENOENT "Нет такого файла или каталога". Я написал простую программу на C для запуска _stati64() в файле, чтобы увидеть, были ли результаты одинаковыми, и она работала правильно.

Дальнейшее изучение с помощью Procmon показало, что процесс, вызываемый через CGI, потерпит неудачу при операции CreateFile в родительском каталоге рассматриваемого файла; результатом всегда был ACCESS DENIED, что является тем же результатом, что и попытка доступа к файлу, который на самом деле не существует.

Исправление оказалось следующим:

  • создание копии исходного родительского каталога и всего содержимого
  • удаление оригинала
  • переименование копии в оригинальное имя

Да, я понятия не имею, что вызвало это, но отладка была очень неприятной проблемой. Я предполагаю, что доступ к CGI не удался из-за неправильных разрешений в исходном каталоге.

0 голосов
/ 02 ноября 2011

Если вы хотите узнать, почему вы получили ошибку, вам следует проверить сообщение об ошибке. Он найден в $!, а точнее в $^E.

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