EoltDima TВремя последнего изменения проверяй.

Ок, допустим пришел злой админ Вася и начал переводить время на работающем сервере. Вперед, назад.
Не поломает ли это алгоритм завязанный на время?
Для хорошего контроля консистентности в серверах баз данных используют вместо времени
счетчик транзакций. Это может быть просто целое число. Это делает систему нечувствительной
к переводу часов.

А вообще знаешь очень сложно обсуждать файловый кеш безотносительно сервера и протокола.

EoltИзопропилХэш сохранять вместе с файлом
Его и проверять при обращении

А если файл 1 гигабайт? А если таких файлов сотня? Сколько будет по-времени считать его хэш?
Столько-же сколько и без кеша. Современные технологии бро... Процессор уже SHA считает.

Eoltmayton,

Чтобы банально прочитать с hdd диска файл в 1 гигабайт уйдет секунд 20 наверное. А если какой то клиент постоянно дописывает к такому файлу по несколько килобайт данных, то сервер будет непрерывно читать его чтобы пересчитать хэш поглотив все ресурсы системы.
Сразу видно что такой вариант не работает.
А теперь давай посмотрим на задачу критически. Тебе тут накидали всяких советов.
Они - правильные. Это как советы одевать тёплые штаны зимой.

Тебе надо обеспечить конкурентный доступ к файлу?
По какому протоколу? Последнее важно т.к. замечено выше что
условные хедеры ( https://developer.mozilla.org/ru/docs/Web/HTTP/Conditional_requests)
решают часть твоих задач для HTTP.

ИзопропилEoltmayton,

Чтобы банально прочитать с hdd диска файл в 1 гигабайт уйдет секунд 20 наверное. А если какой то клиент постоянно дописывает к такому файлу по несколько килобайт данных, то сервер будет непрерывно читать его чтобы пересчитать хэш поглотив все ресурсы системы.
Сразу видно что такой вариант не работает.
Это означает, что этот файл кэшировать бесполезно

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

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

Basil A. SidorovmaytonВообще конкурентный доступ на запись к файлу по сети - это мега-плохо.Эк вы сейчас SMB/NFS опустили ... Прямо ниже плинтуса.
Чел. Этот юзкейс даже для локального файла плох. Несколько разных процессов в произвольное время
что-то пишут. Пускай даже в режиме APPEND. Просто плохо.

Oracle работает атомарно и блочно. И не поверх Samba/NFS.

А разработки "ушастого кота с сигаретой" (автор не обижайся я это с иронией) очень напоминают
строительство БД на файлах. Был там. Знаю. Строили свою такую систему. Но у нах проще было.
Не было конкурентных модификаций. И документы были single-write-only.