C++: размер файла монитора. Это может быть проблематично?

Question

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

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

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? Потому что мне нужно что-то кроссплатформенное и простое в структуре, так как я уже знаю поведение файлов, которые я собираюсь загрузить. К сожалению, boost не дает решения для этого, поэтому мне пришлось изобретать свои собственные.

Answer 1

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

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

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

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

Consistency Файл Флаги

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

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 должен быть очищен при нормальном доступе к файлу и установлен только после того, как согласованность файла гарантируется библиотекой или утилитой согласованности.

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