Как пропатчить ядро, чтобы «дата создания файлов» была?

Ссылка на статью 10 летней давности? Да ну нафиг её.

В ext4 есть дата создания файлов.

$ stat .
  File: .
  Size: 20480     	Blocks: 40         IO Block: 4096   directory
Device: fd00h/64768d	Inode: 2883586     Links: 139
Access: (0755/drwxr-xr-x)  Uid: ( 1000/     lve)   Gid: (  100/   users)
Access: 2018-08-30 14:04:14.684200318 +0300
Modify: 2020-03-17 15:24:03.951926573 +0300
Change: 2020-03-17 15:24:03.951926573 +0300
 Birth: 2018-08-30 14:04:14.684200318 +0300

gnu coreutils возможно нужно обновить.

Я просто хочу хранить фото с реальными датами

Тебе не нужна «дата создания файла», даже больше, тебе не нужны вообще атрибуты файла из ФС.

Есть exif и прочие метаданные, которые в самом простом случае можно добавить в имя файла.

Вот, как пример, всё видно и по имени файла и по метаданным, когда сфоткали, когда скопировали.

$ exiftool IMG_20190718_212207.jpg
...
File Modification Date/Time     : 2020:03:17 16:02:47+03:00
File Access Date/Time           : 2020:03:17 16:02:47+03:00
File Inode Change Date/Time     : 2020:03:17 16:02:47+03:00
...
Modify Date                     : 2019:07:18 21:22:07
Create Date                     : 2019:07:18 21:22:07
Date/Time Original              : 2019:07:18 21:22:07
...

В btrfs тоже всё работает

LC_ALL=C stat file.txt 
  File: file.txt
  Size: 20        	Blocks: 8          IO Block: 4096   regular file
Device: 34h/52d	Inode: 5345588     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/me)   Gid: (  985/   users)
Access: 2020-03-17 16:59:40.166331732 +0400
Modify: 2020-03-17 16:59:21.876332622 +0400
Change: 2020-03-17 16:59:56.462997608 +0400
 Birth: 2020-03-17 16:55:38.786343482 +0400

нет. В этом проблема:

Доступ: 2020-03-17 15:08:53.281006088 +0200
Модифицирован: 2020-03-17 15:08:53.265006089 +0200
Изменён: 2020-03-17 15:08:53.265006089 +0200
Создан: -

Поле пустое

Надо обновить coreutils до 8.31, glibc и ядро.

оставь пожалуйста пару ссылок, с чего начать процесс «патчанья» (для новичков).

dnf/apt upgrade

Поле пустое

Нет, это не поле пустое, это утилита stat из состава coreutils 8.26 не умеет его читать. В ext4 оно есть. Как тот суслик.

Насколько я понял - в рамках вашего Debian 9 это вообще не решается.

Нужен coreutils >= 8.31. И его можно собрать из исходников, только вот HAVE_STATX он проверяет по ядру >=4.11 (там и появился этот патч на который вы ссылку приводили) и glibc >=2.28.

Если ядро можно корректно установить 4.19 из stretch-backports вместо родного 4.9, то корректно установить libc отличную от 2.24 на Stretch нет никаких шансов. Даже вручную запихав deb от Buster (а его можно запихать при желании) - ничего не выйдет при сборке. Не делайте так.

Вам не «ядро патчить» надо. Вам надо «смотрелку» правильную.

Если вы этот же диск, с этими же файлами подключите к любому дистрибутиву, в котором есть coreutils >= 8.31 вы увидите эти даты создания в stat.

Но боюсь вам и этого не надо - как-то слабо себе представляю нормального живого человека, смотрящего на каталог фотографий через консольную утилиту stat. Наверняка же какой-то «проводник» используете, который может совсем иначе читать информацию о файлах. Так думается. (если, конечно, вы не пишете свой собственный «проводник по фотографиям» в bash опираясь на ls --time birth, тогда надо 8.32 версию coreutils).

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

ищу любые способы «смотрения» на дату, включая stat.

Если совсем любые, и обязательно из Debian 9 - посмотрите здесь: http://moiseevigor.github.io/software/2015/01/30/get-file-creation-time-on-li...

Для того чтобы убедиться, что crtime у ваших файлов есть - этого достаточно.

1. Ваше решение не помогло, возможно косо его внеднил, копаю еще.
2. Благодарю за суслика.

Сама идея «неправильной смотрелки» для меня достаточно. Благодарю.

Пожалуйста.

Хотел бы добавить на всякий случай - всё что я писал выше это не тайные, сакральные знания или опыт в ext4. Фактически мы с вами где-то на одном уровне понимания Linux. Просто у меня было лишних 6 часов, любопытство и Гугл. Т.е. всё что написано я перепробовал руками на своём Debian 9 в виртуалке (один раз благополучно его угробив чужим glibc). В том числе тот вариант с выдергиванием crtime из debugfs. Он точно рабочий. 100%.

Вчера вот дошло, что можно же без библиотек - напрямую к ядру делать syscall statx. Ядро всё равно должно быть >4.11, зато ни от чего другого можно не зависеть. Взять ассемблер и вручную int 80h с 332 в rax. Как-то так.

Всего хорошего.

Горе от ума, лол.

1. Объясни
2. Предложи свой вариант

Проблемы не существует, но ты умудрился обосновать её наличие и мужественно ищешь решение.

1. Решения от Toxo2 - не помогло.
2. WitcherGeralt - предложи «свой» вариант решения, вместо отрицания проблемы.

3. Как пропатчить ядро, чтобы «дата создания файлов» была? (комментарий)

Я просто хочу хранить фото с реальными датами.

Шаг 1. Ниче не делай

Шаг 2. Готово

С учётом сложности представленного выше решения, остались ли ещё вопросы по поводу позиции WitcherGeralt?

1. Решение с exiftool провел и:
   -дата слетает после редактирования файла.
   -в некоторых jpg поля EXIF либо зачищены, либо не корректны, поэтому на них я не полагаюсь.
2. Как быть с odt документами?
3. Позиция WitcherGeralt мне не ясна, так как она не озвучена явно.

–
@t184256 подскажи, как мне «увидеть» дату создания файлов? (txt,odt,jpg)
Я реально не понимаю

Как боженька.

1. обновить ядро/glibc/coreutils до нужных версий, можно хоть монтируя на другой системе, хоть методом терпеливого ожидания апдейтов в дебиане, и вызвать stat

2. понять, что нужна тебе все-таки дата съёмки, и взять её из EXIF

1. Похоже нужно переходить на 5-ку, потому как не обновляется, либо я не знаю как это сделать корректно:
   Уже установлен пакет coreutils самой новой версии (8.26-3).
   kernel: 4.19.0-0.bpo.6-amd64
   Debian GNU/Linux 9.12 (stretch)

2. понять, что нужна тебе все-таки дата съёмки, и взять её из EXIF

Возможно это следующий этап, не хочется привязываться EXIF.
У многотысячных файлов дата указана 1970, а моей компетенции пока не хватит все это дело переписать автоматически и корректно.

Похоже нужно переходить на 5-ку,

Это не поможет.
Там Debian 10 Buster, в котором coreutils 8.30 - не будет работать stat так, как вам хочется.

Предлагаю ещё одну попыnку.

Вот здесь https://github.com/whotwagner/statx-fun товарищ уже написал в 2017 году то, что я намедни предлагал вам написать. Вызов syscall statx без библиотеки libc. Т.е. - достаточно только ядра > 4.11

В вашем стиле делать так:

1. подключиться по ssh на вашу машину
2. написать git clone https://github.com/whotwagner/statx-fun.git
3. написать cd ./statx-fun
4. написать make

Если у вас установлены git, gcc, make - всё должно получиться. В каталоге ~/statx-fun появится исполнимый файл statx. Проверено на Debian 9.

Во всей этой истории, мне непонятна одна вещь:
Дата «создания файла» нужна только мне???
Остальным пользователям линукс она не нужна? Или они смотрят другие метрики, по типу EXIF или другим мета-данным без привязки к значениям файловой системы.

Видимо я попал в тупик.

Дата «создания файла» нужна только мне???

Как атрибут ФС, да, мало кому нужна, в отличие от даты модификации.

Применительно к документам, фотографиям дата создания есть в метаданных.

Вопрос, при сохранении файла, допустим из вложения, какая дата будет в атрибутах ФС? Насколько она отражает реалдьную дату создания файла? А в метаданных всё будет красиво.

Как минимум, по EXIF не будет быстрого поиска.

Не обращай внимания на форумных троллей.

Не обращай внимания на форумных троллей.

То есть игнорить ЛОР целиком?

Дата «создания файла» нужна только мне???

Наверное - нет. Раз человек в 2017 это написал, зачем-то оно ему тоже нужно было (и именно так, в ядре, а не через debugfs).

Думаю, что это всё-таки малопригодная характеристика. Она же несёт информацию о дате создания именно текущей ФС. Если в EXIF вы напишете 1969 - оно так и будет ездить с этим файлом. И это будет действительно «дата создания фото». Или в свойствах документа - тоже будет «дата создания документа». А в контексте низкого уровня - дата создания записи в ФС... ну... с разбегу не могу придумать сценарий, когда она нужна на уровне пользователя. Мне так кажется.

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

На правах флуда.

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

Профессиональным фотографам тоже не нужно. У них есть конкретные съемки, они снимают, потом скидывают это в папку.

В винде с датой создания тоже жопа. Если ты скопируешь файл в другую папку, она поменяется.

В маках этой проблемы нет благодаря dmg, а в бсде, думаю, благодаря умной zfs.

Кстати, zfs есть и на линуксе.

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

Применительно к документам, фотографиям дата создания есть в метаданных.

Хотел тебе возразить, но решил прогнать 2 теста:

Тест 1. Открыть старый .odt файл
(лежащий на linux, LibreOfficом c маке по samba и внести правку и проверить выхлоп в мета-данных)
Результат: скрин
Вывод: сохраняет метаданные.

Тест 2. Открыть старый .doc файл
(лежащий на linux, LibreOfficом c маке по samba и внести правку и проверить выхлоп в мета-данных)
скрин
Вывод: сохраняет метаданные.

Странно, потому как еще год назад LibreOfficе НЕ сохранял мета данные и затирал их после редактирования.
Видимо ситуация улучшилась.