Надежный способ определения размера файла в POSIX/OS X с помощью файлового дескриптора

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

NB. Тайм-аут истекает, если файл не увеличивается в течение указанного времени. Таким образом, это не абсолютный тайм-аут, просто тайм-аут, который происходит с файлом. Я на OS X, но этот вопрос предназначен для "каждого POSIX, который имеет kevent() / kqueue() "Это должно быть OS X и BSD, я думаю.

Вот моя текущая версия моей функции:

/**
 * Blocks until `fd` reaches `size`. Times out if `fd` isn't extended for `timeout`
 * amount of time. Returns `-1` and sets `errno` to `EFBIG` should the file be bigger
 * than wanted.
 */
int fwait_file_size(int fd,
                    off_t size,
                    const struct timespec *restrict timeout)
{
    int ret = -1;
    int kq = kqueue();
    struct kevent changelist[1];

    if (kq < 0) {
        /* errno set by kqueue */
        ret = -1;
        goto out;
    }

    memset(changelist, 0, sizeof(changelist));
    EV_SET(&changelist[0], fd, EVFILT_VNODE, EV_ADD | EV_ENABLE | EV_CLEAR, NOTE_DELETE | NOTE_RENAME | NOTE_EXTEND, 0, 0);

    if (kevent(kq, changelist, 1, NULL, 0, NULL) < 0) {
        /* errno set by kevent */
        ret = -1;
        goto out;
    }

    while (true) {
        {
            /* Step 1: Check the size */
            int suc_sz = evaluate_fd_size(fd, size); /* IMPLEMENTATION OF THIS IS THE QUESTION */
            if (suc_sz > 0) {
                /* wanted size */
                ret = 0;
                goto out;
            } else if (suc_sz < 0) {
                /* errno and return code already set */
                ret = -1;
                goto out;
            }
        }

        {
            /* Step 2: Wait for growth */
            int suc_kev = kevent(kq, NULL, 0, changelist, 1, timeout);

            if (0 == suc_kev) {
                /* That's a timeout */
                errno = ETIMEDOUT;
                ret = -1;
                goto out;
            } else if (suc_kev > 0) {
                if (changelist[0].filter == EVFILT_VNODE) {
                    if (changelist[0].fflags & NOTE_RENAME || changelist[0].fflags & NOTE_DELETE) {
                        /* file was deleted, renamed, ... */
                        errno = ENOENT;
                        ret = -1;
                        goto out;
                    }
                }
            } else {
                /* errno set by kevent */
                ret = -1;
                goto out;
            }
        }
    }

    out: {
        int errno_save = errno;
        if (kq >= 0) {
            close(kq);
        }
        errno = errno_save;
        return ret;
    }
}

Итак, основной алгоритм работает следующим образом:

  1. Настройте кевент
  2. Проверьте размер
  3. Ждите роста файла

Шаги 2 и 3 повторяются, пока файл не достиг желаемого размера.

Код использует функцию int evaluate_fd_size(int fd, off_t wanted_size) который вернется < 0 для "произошла какая-то ошибка или файл больше, чем хотел", == 0 для "файл еще не достаточно большой", или > 0 для файла достиг желаемого размера.

Очевидно, это работает только если evaluate_fd_size надежно определяет размер файла. Моим первым шагом было реализовать это с off_t eof_pos = lseek(fd, 0, SEEK_END) и сравнить eof_pos против wanted_size, К несчастью, lseek похоже кеширует результаты. Так что даже когда kevent вернулся с NOTE_EXTEND, так что файл вырос, результат может быть таким же! Тогда я подумал переключиться на fstat но нашел статьи, которые fstat кеши тоже.

Последнее, что я пытался использовать fsync(fd); до off_t eof_pos = lseek(fd, 0, SEEK_END); и вдруг все стало работать. Но:

  1. Ничто не утверждает, что fsync() действительно решает мою проблему
  2. Я не хочу fsync() из-за производительности

РЕДАКТИРОВАТЬ: это действительно трудно воспроизвести, но я видел один случай, в котором fsync() не помогло Кажется, что потребуется (очень мало) времени, чтобы размер файла увеличился после NOTE_EXTEND событие попало в пространство пользователя. fsync() наверное просто работает достаточно хорошо sleep() и поэтому он работает большую часть времени:.

Итак, другими словами: Как надежно проверить размер файла в POSIX без открытия / закрытия файла, что я не могу сделать, потому что я не знаю имени файла. Кроме того, я не могу найти гарантию, что это поможет

Кстати: int new_fd = dup(fd); off_t eof_pos = lseek(new_fd, 0, SEEK_END); close(new_fd); не преодолел проблему кеширования.

РЕДАКТИРОВАТЬ 2: Я также создал все в одной демонстрационной программе. Если это печатает Ok, success перед выходом все прошло нормально. Но обычно это печатает Timeout (10000000) что проявляется в состоянии гонки: проверка размера файла для последнего запущенного кевента меньше, чем фактический размер файла в данный момент. Странно при использовании ftruncate() вырастить файл вместо write() кажется, работает (вы можете скомпилировать тестовую программу с -DUSE_FTRUNCATE чтобы проверить это).

Источник

1 ответ

  1. Ничто не говорит о том, что fsync() действительно решает мою проблему
  2. Я не хочу fsync() из-за производительности

Ваша проблема не в "результатах кэширования fstat", а в записи буферизации системы ввода-вывода. Fstat не обновляется, пока ядро ​​не сбросит буферы ввода / вывода в базовую файловую систему.

Вот почему fsync решает вашу проблему, и любое решение вашей проблемы более или менее должно быть эквивалентно fsync. (Это то, что решение открыть / закрыть делает как побочный эффект.)

Не могу помочь вам с 2, потому что я не вижу способа избежать fsync.

Источник
Другие вопросы по тегам