LINUX.ORG.RU

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

 , ,


0

1

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

Вводные:

  1. Debian 9 (файловое хранилище с фото на ext4.)
  2. 3 диска: первый системный, и два по терабайту - это само храниище.)

Проблема:

  • отсутствует поле «дата создания файла» на несистемном винте.
  • при редактировании файла (doc,jpg) - дата создания заменяется датой последнего обращения (файлы редактирую по smb и по ssh).

Предварительные понимания: Википедия говорит, что ext4 - хранит дату создания файла, а по факту это не так. Решения, которые встречал в сети упираются в то, что мол:

  • хранение даты это нестандартная фича,
  • по дефолту отключена для несистемных дисков, дабы ускорить работу системы.
  • патчить ядро чтобы включить фичу. (Линк на патч ядра - https://lwn.net/Articles/394391/)

З.Ы.

  1. Я просто хочу хранить фото с реальными датами.
  2. На Фре и Mac - дата сохраняется.

Прошу помощи у знающих.

Ссылка на статью 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 возможно нужно обновить.

vel ★★★★★ ()

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

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

Есть 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
...
vvn_black ★★★★★ ()
Последнее исправление: vvn_black (всего исправлений: 5)

В 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
kostyarin_ ()
Ответ на: комментарий от ravaya

Поле пустое

Нет, это не поле пустое, это утилита 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).

Toxo2 ()
Ответ на: комментарий от Toxo2

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

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

ravaya ()
Ответ на: комментарий от ravaya

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

Пожалуйста.

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

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

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

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


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

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

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

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

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

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

ravaya ()
Ответ на: комментарий от ravaya

Похоже нужно переходить на 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.

Toxo2 ()
Ответ на: комментарий от Toxo2

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

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

ravaya ()
Ответ на: комментарий от ravaya

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

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

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

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

vvn_black ★★★★★ ()
Ответ на: комментарий от ravaya

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

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

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

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

Toxo2 ()
Последнее исправление: Toxo2 (всего исправлений: 1)
Ответ на: комментарий от ravaya

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от ravaya

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

Result-Code ()
Ответ на: комментарий от vvn_black

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

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

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

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

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

ravaya ()
Последнее исправление: ravaya (всего исправлений: 1)