lseek/write вдруг возвращает -1 с errno = 9 (Bad file descriptor)

Question

Мое приложение использует lseek() для поиска желаемой позиции для записи данных. Файл успешно открыт с использованием open(), и мое приложение смогло использовать lseek() и write() много раз.

В данный момент для некоторых пользователей и нелегко воспроизводится lseek() возвращает -1 с errno из 9. Файл не закрывается до этого, и дескриптор файла (int) не сбрасывается.

После этого создается другой файл; open() снова в порядке, и lseek() и write() снова работает.

Чтобы сделать это еще хуже, этот пользователь снова попробовал полную последовательность, и все было хорошо.

Итак, мой вопрос: может ли ОС закрыть файл для меня по какой-то причине? Что может быть причиной этого? Файл индексатор или сканер файлов?

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

int fd=open(...); 
if (fd>-1) { 
    long result = lseek(fd,....); 
    if (result == -1 && errno==9) { 
     close(fd..); //make sure we try to close nicely 
     fd=open(...); 

     result = lseek(fd,....); 
    } 
} 

опыта кто-нибудь с чем-то подобным?

Реферат: Файл ищет и пишет работает нормально для данного fd и внезапно возвращает errno = 9 без причины.

Answer 1

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

Если файл/устройство, которое вы открываете, реализовано как серверное приложение (например, NFS), подумайте, что может произойти, если серверное приложение отключится/перезагрузится/перезагрузится. Дескриптор файла, хотя он был первоначально действителен на стороне клиента, может больше не сопоставляться с допустимым дескриптором файла на сервере. Это может привести к последовательности событий, в которых клиент получит EBADF.

Надеюсь, это поможет.

Answer 2

ОС не должна закрывать файловые манипуляции случайным образом (я предполагаю Unix-подобную систему). Если ваш дескриптор файла закрыт, значит, что-то не так с вашим кодом, скорее всего в другом месте (благодаря языку C и Unix API это может быть действительно в любом месте кода и может быть вызвано, например, небольшим буфером переполнение в некотором фрагменте кода, который действительно выглядит не связанным).

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

Предлагаю вам добавить отладочные отпечатки (т. Е. printf() звонки), где бы вы ни открывали и не закрывали файл или сокет. Также попробуйте Valgrind.

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

Answer 3

Нет, ОС не должна закрывать дескрипторы файлов именно так, а другие приложения (сканеры файлов и т. Д.) Не должны быть , способным сделать это.

Не обходите проблему, найдите ее источник. Если вы не знаете, в чем причина вашей проблемы, вы никогда не узнаете, действительно ли ваш обходной способ делает работы.

1. Проверьте свои предположения. Действительно ли errno установлен на 0 перед вызовом? Действительно ли fd действительно в момент вызова?(Я знаю, что вы это сказали, но сделали ли вы check?)
2. Каков объем производства puts(strerror(9)); на вашей платформе?

Answer 4

Итак, мой вопрос: может ли ОС закрыть файл для меня по какой-то причине? Что может вызвать это? Файл индексатор или сканер файлов?

Нет, этого не произойдет.

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

Нет, лучший способ, чтобы найти ошибку и исправить ее.

У кого-нибудь опыт с чем-то подобным?

Я видел FDS получать перепутались много раз, в результате чего EBADF в некоторых случаях, и раздутия эффектно в других, это было:

• переполнение буфера - переполнение что-то и записывая бессмысленное значение в 'int fd;' переменная.
• глупые ошибки, которые происходят из-за какой-то угол случай кто-то сделал if(fd = foo[i].fd) когда они имели в виду if(fd == foo[i].fd)
• Raceconditions между нитями, какой-то поток закрывает неправильный дескриптор файла, другой поток хочет использовать.

Если вы можете найти способ воспроизвести эту проблему, запустите свою программу под «strace», чтобы вы могли видеть, что происходит.