API fail

[stas]

API fail: Linux stores file creation timestamp (on most filesystems). stat() has structures to retrieve it. CLI tools have formats and UI to support it. But Linux kernel just doesn't return file creation TS, despite having it. Why? Because shut up, that's why.

Comments

[gb0]

Не просто shut up. Shut up and do it. FOSS же.

[sab123]

Непонятно, зачем такое время может быть нужно.

[stas]

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

[stas]

Ну, добавить новый kernel API не каждому под силу :) Хотя есть способы, там же по линку описанные, но в основном требуют root и много красноглазия.

[gb0]

Линупс и красноглазие – прям как Michelle и ma belle – tres bien ensemble. FOSS не означает несправедливости TANSTAFL. There (still) Ain't No Such Thing As a Free Lunch.

[stas]

Ну всё-таки предлагать юзерам системы быстренько добавить API в kernel - это немного выходит за рамки разумного.

[spamsink]

"Because POSIX doesn't require it, and we're lazy."

[http://users.livejournal.com/sorcerer-/]

Не понял в чем проблема, ну нет стандартного API для этого. Мало того не все файловые системы это поддерживают.
Какой надо было изобресть?
А еще у меня есть несколько вопросов:
1. Вот берем тар, тарим в архив какие-то файлы, стираем все, антарим архив в то же место. Какие должны быть "birth" таймстемпы?
2. Тот же вопрос, но немного сбоку: кончается место в /var, подключаем новый диск, бэкапим на него /var, маунтим тот диск под /var-ом, какое поведение ожидается?

[http://users.livejournal.com/sorcerer-/]

это не API в кернел. а тупо в драйвер конкретной FS дописать. раз уж хочется завязаться на нее.

[stas]

Файловые системы могут много чего не поддерживать, с этим работать все умеют, это не бином ньютона.
1. Зависит от значение "стираем всё". Таймстемп, натурально, когда запись в каталоге создана. Если запись удалили (unlink), потом снова создали - новый таймстемп. Если запись в каталоге та же, а содержимое файла заменили - возле птицы.
2. Не понял вопроса. Ожидается обычное поведение файловой системы. Вы какие-то загадки загадываете, но эти таймстемпы УЖЕ работают. Они УЖЕ есть. Просто кернел линукса их по какой-то причине (лень и похуизм) не отдаёт в userspace. Чего, спрашивается, гадать, какое поведение? Какое есть, такое и есть.

[stas]

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

[stas]

In this case, laziness is not a virtue.

[http://users.livejournal.com/sorcerer-/]

Если нужно настолько нестандартное не-POSIX поведение, то можно и драйвер написать.

[stas]

Можно и новую ОС написать, чего уж мелочиться. Если нечего больше делать.

[http://users.livejournal.com/sorcerer-/]

Мне интересно тогда, какое поведение апликации может рассчитывать на birth timestamp, если оный таймстемп может под апликацией незаметно поменяться?

[http://users.livejournal.com/sorcerer-/]

Ну, если надо, то и ос пишем. А че делать, никто не обещал, что будет легко.
Ключевой вопрос: надо ли?

[stas]

Незаметно поменяться может любой таймстамп, тоже мне удивительно - вроде другие таймстампы никогда не меняются? Не вижу, в чём тут проблема. На любой файловой системе может внезапно поменяться ровно всё, однако как-то живём же. Эдак можно вопрошать "да как же можно сделать команду ls, если содержимое диска может всё время меняться?!". Ну так и можно.
В stat это кстати давно есть, %w и %W. Но толку ли, если кернел данные не отдаёт.

[http://users.livejournal.com/sorcerer-/]

Еще раз: какое поведение апликации завязано на такие таймстемпы?
В обычном линуксе есть ключи к tar и другим утилитам, которые позволяют таймстемпы _сохранять_, мой вопрос был о том как сохранять и этот таймстемп?
Переписать еще и tar, cp, mv и еще кучу? Сказать, что поведение их undefined? Другая смешная опция?

[stas]

Да пофиг. GNU tools наверняка уже поддерживают, если stat поддерживает, то и другие. Поведение очень простое - показать пользователю (мне) таймстемп создания файла. Тоже непонятно, какая разница. Это не дело кернела, знать поведение апликаций. Его дело - структурки в stat(2) заполнять. Надо поддержать tar - ну хорошо, сделайте и utimes(2), делов-то. А не хотите, так и не надо. Такое впечатление, что прямо полёт на марс какой-то. Уже всё давно известно и на 99% сделано.

[http://users.livejournal.com/sorcerer-/]

P.S. Это я на самом деле к тому, что если не переписывать tar и cp, то после tar -cpf и cp -a (описанные в пп. 1 и 2) у нас будут все таймстемпы (включая last modification time) _меньше_, чем birth.

[stas]

Ну, допустим, будут. И что? А если использовать utimes, то у файла на Линуксе может быть таймстемп модификации в 1970-м году, когда никакого линукса ещё не было. Ну и что? Кого это должно парить?

[http://users.livejournal.com/sorcerer-/]

Хмм, это была хорошая мысля.
Посмотрел быстренько в код gnu tar, и таки я прав, не используется нигде get_stat_birthtime_ns(), хоть и объявлен.

[http://users.livejournal.com/sorcerer-/]

Скорее всего апликация, завязанная на такое поведение, сделает что-то не то, а если это поведение не обязательно, то и поддерживать не обязательно.

[stas]

Какое "такое" поведение? Это какая-то странная мысль. Всё равно, что сказать "если написать в документе html фигню, то браузер покажет фигню, а если можно хранить документы и не в html, то поскольку это не обязательно, то браузеры писать не надо". Какая-то бессмыслица.

[http://users.livejournal.com/sorcerer-/]

> Какое "такое" поведение?

На поведенеие, где для чего-то требуется знать именно birth time, и не достаточно last modification.
Т.е. у меня нет идей зачем это надо, поэтому уже over 9000 букв я прошу узнать зачем кому-то это надо?

[stas]

Ну мне было вчера надо. Зачем - долго обьяснять, да и какая разница, но нужно было знать, когда создан определённый файл. Время модификации - совершенно другой таймстемп, никакого отношения, это всё равно, что спрашивать "зачем вам моё имя, если вы знаете размер моих ботинок?". Никакой связи между last mod и birth time нет, вообще.

[mtve]

> Таймстемп, натурально, когда запись в каталоге создана.

может всё-таки inode?

[stas]

да как угодно, лично мне эти тонкости безразличны :)

[scaredy_cat_333]

Вносить в ядро расширения к позиксу - вызывать проблемы при смене ОС. На это, как я понимаю, в линуксе вполне идут. См. напр. расширенные файловые атрибуты. Но вносить в ядро расширения не всеми файловыми системами в самом же линуксе поддерживаемые - вызывать проблемы типа на этом файле программа работает, а на этом почему-то нет. Паранойю в ЭТОМ месте можно только приветствовать.

[stas]

Не вижу смысла в этом обьяснении. Разумеется, у разных ФС есть разные поддерживаемые возможности. Например, некоторые не поддерживают файлы, различающиеся только регистром. Некоторые записывают время доступа с секундной точностью, некоторые - с более секунды, некоторые - с менее, а некоторые вообще не записывают (noatime). Так что теперь, отменять имена у файлов и время доступа? Очевидно, что если ФС не поддерживает конкретную возможность - возвращайте нолик или EINVAL в соотв. функции или ещё что такое. Прямо как будто последних 50 лет развития индустрии не было и мы выдумываем с нуля как ОС писать. Камон.