filemtime/filectime в будущем — насколько корректно?

filectime — это что, change или create time? И как вы собраетесь его менять?

А первая же проверка диска, ЕМНИП, вернёт все атрибуты из будущего в текущее время. Причём, проверка не обязательно из-за некорректного отключения питания, дотстаточно штатного ребута, по умолчанию в ext2 и потомках установлениа проверка через двадцать или около того монтирований или полгода без проверки.

filectime — это что, change или create time?

В Linux есть change, но нет create :)

А первая же проверка диска, ЕМНИП, вернёт все атрибуты из будущего в текущее время

Проверки диска дату не трогают, проверено многократно :)

Рад за вас, что вам так весело, но всё таки, вы не ответили на вопрос о том, чем вы собрались изменять ctime.

Если счиать что современный linux это ext4, то очень давно есть create time, cp и атрибуты файла . Я тут просто надеялся, что у гентушников, которые впереди всех, уже давно всё подпаченно, чтобы create time можно было видеть через обычные команды, а не только через debugfs, а получается, что они даже не в курсе.

Пока что проверки не трогают, хотя вот есть такой патч https://lkml.org/lkml/2013/11/13/43 , не знаю, принят ли он, да и 2311 год не скоро, но кто знает :-) В том плане, что вдруг кому из создателей e2fsck захочется проверять даты и исправлять их, и тогда ваша система сломается, удалит все файлы и придётся придумывать что-то другое.

Я бы использовал xattr или так бы и хранил в БД и отдельный скрип для проверки что содержимое БД синхрнонизированно с диском, может быть, скрипт-обёртка над stat, выдающий ещё и время хранения по результату запроса в БД.

но всё таки, вы не ответили на вопрос о том, чем вы собрались изменять ctime

Это же вопрос общей концепции. Ок, не ctime, а atime. Так — лучше?

Я тут просто надеялся, что у гентушников, которые впереди всех, уже давно всё подпаченно

Не знаю, что там у гентушников, у меня эта задача стоит на референсных Ubuntu и CentOS.

Пока что проверки не трогают

Вот и славно.

Я бы использовал xattr или так бы и хранил в БД

В первом сообщении я писал и про xattr, и про БД.

Но случается так, что по тем или иным сбоям часть файлов оказывается не удалённой, хотя из БД запись уже исчезнет.

Так может случаться потому, что удаление файла и записи из БД - не одна атомарная операция (когда, например, запись удаляется даже при ошибке удаления файла).

Есть ли более изящное решение, или этот вариант не плох?

Этот вариант плох потому, что не стоит хранить признаки удаления данных за пределами ответственности удаляющего кода. То есть, по ФС с данными лазят все кому не лень (демоны, юзеры и т.п.) и могут сотворить с этими признаками что угодно. А ты потом по ним решаешь, удалять данные или нет. С таким же успехом можно удалять в зависимости от $RANDOM.

Чтобы не мучиться со связыванием и синхронизацией этих данных с файлами на ФС, почему бы не хранить их прямо в именах файлов? Тем более, что речь идёт о файлах некоего кеша, а не произвольных пользовательских.

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

На референсный Ubuntu и CentOS ФС будет смонтирована с noatime? Хотя по умолчу relatime, тоже, должен подойдйти. Попробуйте, потом раскажите...

А насчёт xattr я не понял, где и чем она не индексируется? SeLinux живёт в xattr и ничего, как-то работает.

Но что делать с картинками?

Раржпег.

JSON?

/* */ Можешь ещё вайтспейсами кодировать:3 Эй, я придумал новый вид стеганографии!