таймер — C ++: контролировать размер файла. Может ли это быть проблематичным?

Я пишу программу с графическим интерфейсом, которая синхронизирует файлы в папке с сервером. Информация, которую я знаю об этих файлах, состоит в том, что они всегда пишутся, а не удаляются. Моя задача — начать загрузку файла во время его записи. Поэтому, чтобы избежать этого, я изобрел способ решения проблемы, и мне нужен какой-то эксперт, который скажет мне, что это не так.

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

std::size_t GetFileSize(const std::string &filename)
{
std::ifstream file(filename.c_str(), std::ios::binary | std::ios::ate);
return file.tellg();
}

Затем я сохраняю имя файла (ов), размер в структуре данных формы (игнорируя std:: чтобы сделать его визуально удобным, так как в следующей строке должно быть написано 5):

deque<pair<string, pair<size_t, long> > fileMonitor;

(пожалуйста, предложите лучшую структуру данных, если это возможно. unordered_multimap кажется, делает аналогичную работу).

Таким образом, в нем будут храниться имя файла (в этой строке), его размер (в этом size_t) и количество проверок размера файла без изменений, давайте назовем его checks, Поэтому каждый раз, когда срабатывает таймер, я ищу новые файлы и проверяю, fileMonitor изменился Для одного файла, если размер файла отличается от предыдущего, то checks = 1, и если размер файла такой же, то я делаю checks++,

Теперь в каждой итерации я проверяю таймер interval*checks > timeoutто файл не менялся достаточно долго, и я могу судить, что файл стабилен и не обновляется.

Очевидный вопрос: почему я не использую что-то вроде inotify? Потому что мне нужно что-то кроссплатформенное и простое по структуре, так как я уже знаю поведение файлов, которые я собираюсь загрузить. К сожалению, повышение не дает решения для этого, поэтому я должен был изобрести свой собственный.

0

Решение

У вас есть доступ к программе письма? В этом случае я бы рекомендовал сначала записать данные во временный файл и переименовать его только после того, как запись была завершена ( atomic работа в файловой системе). В противном случае ваш «ждать соответственно долгое время для изменения» Подход всегда может потерпеть неудачу, потому что вы не можете определить причину, по которой пишущая программа не изменяет файл в течение длительного времени.

  • дополнения для формата HD5:

Файлы могут даже изменить содержимое без изменения его размера но:

От https://www.hdfgroup.org/HDF5/doc/H5.format.html#FileMetaData

Флаги согласованности файлов

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

Bit 0 set indicates that the file is opened for write-access.
Bit 1 set indicates that the file has been verified for consistency and is guaranteed to be consistent with the format defined

в этом документе.
Биты 2-31 зарезервированы для будущего использования.

Бит 0 должен быть установлен как первое действие, когда файл открывается для
доступ на запись и должен быть очищен только как последнее действие, когда
закрытие файла. Бит 1 должен быть очищен при обычном доступе к файлу
и устанавливается только после того, как согласованность файла гарантируется библиотекой
или утилита согласованности.

Я бы предположил, что API-интерфейсы HD5 предоставляют методы для исключительно откройте эти файлы и попробуйте это в дополнение к вашему подходу опроса.

0

Другие решения


По вопросам рекламы [email protected]