Архивирование и разархивирование

Ты так и не объяснил зачем тебе дата создания, учитывая что «когда снято видео» - это дата модификации.

Дата создания - постоянная величина, она не меняется при редактировании файла. По нему можно сортировать, искать файлы.

Или например вижу файл а дата создания в нем 2010 год, тут то я и вспомню как и при каких обстоятельствах я создал этот файл) История! Чего бы и нет?
В любом случае, как по мне, то очевидно что лучше знать два знания чем один - дата модификации.

Не похоже, что birth time много где поддерживается. Проще всего будет использовать встроенные метаданные (EXIF для фото, что-то там в MKV и прочие) или xattrs. Но xattrs тоже легко потерять, если в какой-то момент забыть указать параметры для архиватора.

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

Как вариант видел советы поменять дату в системе на дату в прошлом, сохранить файл, поменять дату обратно, … профит.

Нормальные способы это хранить дату в имени файла или в EXIF

Какого ещё редактирования? Ты hex-редактором снятое видео правишь?

То что ты описываешь принято хранить именно в дате модификации - это время, когда был сгенерирован контент, хранящийся в файле. Все копирующие/архивирующие программы относятся к ней бережно. А «дата создания» это не пойми что, просто техническая информация о том когда была создана инода. И когда ты редактируешь файл в чём-то, велик шанс что он вовсе не будет писать результат в старую иноду, а создаст новую (с новой датой, соответственно), запишет в неё исправленный вариант, а старю удалит - это для того чтоб не потерять содержимое файла если в момент его перезаписи случится какая-то ошибка. Если ты перекодируешь видео то результат будет, конечно, в новом файле, и шанс того что перекодировщик при этом и думать не будет про какие-то даты создания - около 100%.

Вобщем забей на эту штуку и храни в дате модификации важную для тебя дату, связанную с файлом, как все делают.

Лучше конвеером.

Я использую

tar cvp --one-file-system \
--exclude=/home/rrr/.cache \
--exclude=/home/rrr/.thumbnails \
--exclude=/home/rrr/pass \
--exclude=/home/rrr/downloads \
--exclude=/home/rrr/Downloads \
/home/rrr | nice -n20 pigz -3 -p4 > /media/pi3/data/pi4home_"$DATE".tar.gz && \
mv /media/pi3/data/pi4home_"$DATE".tar.gz /media/pi3/data/backup/zback_tmp/

Итого получается tar cvp <папка> | <архиватор>

zstd конкурирует с lzma2, причём иногда даже выигрывает, ещё и по силе сжатия. При этом он несомненно легче и быстрее. И боле гибкий - умеет как быстрое и лёгкое, так и крутое сжатие.

Он просто самый новый из всех алгоритмов. lzma уже 20 лет в обед, а lzma2 это так, косметика.

Дата создания стала текущего времени, именно когда распаковал.

Что вообще то логично... Тут думать надо.

Нашёл опции tar:

-m При извлечении игнорировать время модификации объекта.
--atime-preserve Оставить прежнюю метку времени доступа для файла.
--same-owner Сохранить владельца при извлечении.

ну это время доступа и все такое…

видео просто для примера, софт, видео, картинки, образы дисков, бекапы, архивы, пдфки…..

Кому интересно, проверил pixz, это такой улучшенный xz с индексацией, вот результаты:

pixz
Сжатие:     16min 31sec 426ms 12µs 373ns (уровень 15; итог: 8,4 ГиБ)
Распаковка:  4min 24sec 364ms 58µs 490ns

7z
Сжатие     44min 18sec 501ms 949µs 755ns (уровень 9 + mmf=bt; итог: 8,3 ГиБ)
Распаковка  4min 859ms 895µs 628ns

Пока проверял, заметил что 7z использует куда меньше из доступных ресурсов и соответственно сжимает дольше, pixz же использует по максимуму сразу всё что ему доступно.

7z использует куда меньше из доступных ресурсов и соответственно сжимает дольше

Там есть опции тюнинга, как в win GUI, только в ещё больее широких пределах. Можно что угодно накрутить. А по умолчанию там «много думать» но 700м-2гб памяти.

И что? Везде ответ тот же - используй дату модификации для своих целей.

Cпасибо но нет, будем дальше думать. На худой конец запущу Тотаl commander через wine.

Ради чего этот мазохизм с нецелевым использованием этого поля?

чтобы знать когда создавался тот или иной файл

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

Нет, то что ты описал - это не дата создания ФАЙЛА а дата создания контента в нём. Если ты распаковываешь архив то файлы создаются новые, и дата создания у них, как и положено, новая. Старый у них контент и его дату все архиваторы тоже восстанавливают.

элементарно ватсон %)
нужна метатеги содержимого - пропиши эти метатеги в формате содержимого.
смотри соответственно EXIF.

это не дата создания ФАЙЛА а дата создания контента в нём.

Крайне дискуссионный момент. Если я сейчас на арче своем создам архив с картинками либо просто образ чего то..(сейчас 20240827) то в файловом менеджере поле дата создания, будет 20240827, через года три дата создания останется точно таким же.
Простая логика - это дата создания моего файла. Разумеется, если скопирую на другой диск либо архивирую и распакую то дата создания изменится. Вот я и ищу способ обогнуть это препятствие.

Если на винде распаковывать 7зипом как я описал по ссылке то все!! даты остаются такими как были. Ничего не меняется. То же самое про копирование файлов на другой диск тотал коммандером(его надо чуть настроить) - даты останутся такими же как были.

Архивирование и разархивирование (комментарий)

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

Само же дата создания и модификации записывается наверное не в файл а куда то в файловую систему..

Простая логика - это дата создания моего файла

Это не простая логика, возникает вопрос, что такое дата создания файла?

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

При нажатии кнопки сохранить создавать новый файл .tmp (соответсвенно с текущей датой создания), удалять старый и переименовывать новый в старый. При этом и дата модификации изменится на текущую.

Получается свою реальную «дату создания» файла знаешь только ты, и ее надо хранить в имени файла/в тегах/отдельной базе (файлике) и тд.

Да, верю, что некоторые инструменты в некоторых операционных системах могут куда-то рядом с файлом автоматически положить и даже перенести «дату создания» файла при копировании, но это не стандарт и линукс так не может.

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

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

При нажатии кнопки сохранить создавать новый файл .tmp

Если я на линуксе доупстим создам файл, сейчас, дата создания будет 20240827, завтра(или через час.. для краткости написал только дату) отредактирую этот текстовый файл то дата создания изменится?

Как то не верится..

нет :)
пока ты его не скопируешь.
при копировании создастся новый файл с новой датой создания и в него скопируется содержимое исходного. это если без доп.телодвижений.

ну это очевидно, при копировании создается новый файл, я же нигде это не опровергал?

Да, например, попробуй отредактировать файл в LibreOffice

в ntfs есть, к примеру, функциональность дополнительных потоков данных для файлов, в которых можно хранить кучу информации, не меняя исходный файл (точнее говоря, основной поток файла).
это с одной стороны удобно - помнится, dc++ в таком потоке сохранял хеш-сумму файла. и еще несколько применений было но не вспомню.
при копировании с ntfs на ntfs средствами винды доп.потоки сохранялись. при копировании на фс не поддерживающие доп.потоки (fat естественно) они, естественно, дропались :) с другой стороны некоторые вирусы научились прятать в этих потоках всякое левое.
да и вообще мало кто про это даже знает :)

Если я сейчас на арче своем создам архив с картинками либо просто образ чего то..(сейчас 20240827) то в файловом менеджере поле дата создания, будет 20240827, через года три дата создания останется точно таким же.

Ты так и не объяснил чем тебя не устраивает дата модификации. Она как раз будет 20240827 и при всех копированиях или архивациях будет сохраняться как ты хочешь.

Если я на линуксе доупстим создам файл, сейчас, дата создания будет 20240827, завтра(или через час.. для краткости написал только дату) отредактирую этот текстовый файл то дата создания изменится?

Да, может именно такое произойти. Зависит от того какой редактор и какие у него настройки. Повторяю в который раз, на дату создания плевать практически всем и никто не парится её как-то поддерживать. Если она поддерживается то скорее всего не потому что автор проги этим озаботился, а потому что просто повезло что логика её работы её случайно не портит.

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

с другой стороны некоторые вирусы научились прятать в этих потоках всякое левое.

Как и антивирус Касперского.😀 Не знаю, делает ли он так сейчас.

На худой конец запущу Тотаl commander через wine.

Просто никогда не храни важную информацию в atime/mtime/ctime, это ненадёжное место хранения.

P.S. Эпидемия что ли какая началась, за полгода ты третий человек, хотящий подобных странностей.

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

а потом внесешь изменения и пиши пропало

Куда ты изменения внесёшь? В видео? Дата создания точно так же изменится т.к. видеоредактор создаст новый файл.

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

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

Ну сколько тебе повторять что ты неправильно понимаешь суть этого поля? Поверь уже просто и хватит упрямиться.

дата создания

Вряд ли есть простой способ, так как функции futimens/utimensat/utimes поддерживают задание только времён доступа и модификации.
Когда-то давно Far3 стал использовать низкоуровневые функции Windows, что позволило редактировать в нём четыре времени файлов. Возможно, что он единственный ФМ, который это позволяет.

дата создания как тебе уже несколько раз объясняли такой же непостоянный параметр.
в принципе как и все остальные параметры :)

на винде она постоянна!! Значит и тут можно. Я докажу как найду способ, отпишусь. Как найду.

так можно доиграться и хранить свои метаданные внутри иноды :)
но распространение и поддержка ентового будет только на твоем компе.

Что все так прицепились к видео? Видео тут совсем не при чем. Забудьте все про видео. Нет никакого видео.

Архив, в архив внесу изменения. Дата создания останется таким же как и было. А дата модификации поменяется - все по логике.

И «текстовые» файлы я тоже редактировал разными редакторами - дата создания не менялся.

да вот фиг.
создал файл на диске Д

Время последней записи:             27.08.1994  13:56:53,8759000
Время создания:                     27.08.1994  13:56:53,8749000
Время последнего доступа:           27.08.1994  13:56:53,8749000
Время изменения:                    27.08.1994  13:57:14,3749000

скопировал на диск Ц

Время последней записи:             27.08.1994  13:56:53,8759000
Время создания:                     27.08.2024  13:57:34,0399000
Время последнего доступа:           27.08.2024  13:57:34,0399000
Время изменения:                    27.08.1994  13:57:14,3749000

упппс :)
и это через правоверный винэксплорер.

по моему никто не пишет что я пишу))))

Тотал коммандером копируй!! А перед этим этим настрой тотал коммандер чтобы он даты.. сохранял!

Даже поискал.. если не ошибаюсь надо в wincmd.ini

CopyDirTimeStamp=1
CopyAllTimes=1

текстовый редактор ворд при использовании .docx, который представляет собой zip архив контекста данных, перезаписывает файл каждый раз.

ну дык приколхозить костыль можно везде. ты тогда уж не про «винду vs линукс» говори? а про «тотал командер vs остальной мир» :)
тоталом пользовался както лет очень много назад, под него плагин написали для маилру облака, потом появились лучшие альтернативы и тотал до сих пор гдето пылится.

это не колхоз а решение. На винде я архивы делаю 7 зипом(опенсоурс и все такое…), файлы на другой диск копирую тоталом(можно хеш суммы проверять при копировании - надежно!). Даты создания постоянны.

На линуксе уверен тоже есть решение.

На линуксе уверен тоже есть решение.

Пока нет, но уверен, что ты его напишешь 👍

На линуксе уверен тоже есть решение.

https://stackoverflow.com/questions/68326170/changing-the-files-creation-timestamp-in-linux-programmatically-in-c-c

There seems to be no easy way to access the creation time - a quick search reveals that ext4’s i_crtime is not directly modifiable.

A possible solution is to write a filesystem-specific driver to modify e.g. i_crtime directly - but this carries its own risks in modifying internal filesystem data.

Есть ещё варианты с debugfs. Но вообще не похоже, что кто-то хотел разрешить юзерспейсу трогать crtime и ctime на своё усмотрение, и это кажется логичным.

debugfs

Только для ext*. Что там у ТС – неинтересная загадка.

btrfs, писал в комментах. Надо было конечно в пост добавить. Добавил.