Linux FAT File Creation/Birth Time Reporting, Proposal For Statx I/O Alignment Info

[Old Grouch]

Like someone asked:

What exactly would “creation date” mean, though? If I do

cp -a file1 file2

should file2 be given the same creation date as file1? Or should it be given a creation date of now?

It depends on what you think 'creation data' should mean. Is it the creation data of the logical construct; or the date some magnetic domains were rearranged to represent the logical construct? I term the former the inception date, and the latter the creation date (of that instance) - or you could call it the instantiation date.

Basically you are mixing two separate concepts, one of which is more 'meta' than the other.

A file is a particular arrangement of bits, often represented as an arrangement of magnetic domains on a disk. The first time that particular arrangement is laid down is the creation date for that file, but it is also the date of the creation of the particular arrangement of bits. If you copy it to another location, the new location has its domains (re)arranged at a later date, which is the creation date of the copy. However as a like-for-like copy, you can say that the first time that logical arrangement of bits came into existence was at the time of the creation of the first file. So you have two creation dates. I regard the rearrangement of magnetic domains as being separate creation dates, but the date at which the logical arrangement of bits first appeared is the 'inception date'.

Of course, depending on your philosophy on the existence of numbers, all possible numbers exist. In which case, logically, all logical arrangements of bits already exist, so the first time an arrangement is thought of causes it to be reified. So instead of inception date, perhaps reification date.

[Old Grouch]

" > I am trying to read a file which has several lines of data, modify [...]

Modifying a file at a specific location is tricky. Generally it's much easier to create a new file, copying lines from the original file and changing as needed, and then rename the new file to the original name when you're done."
-- https://stackoverflow.com/questions/...-file/56531548

ISAM files exist to enable in-file replacement of data, amongst other things. There are other approaches, including well known relational databases.

[Adarion]

Oh my, time stamps on files... "You are entering a world of pain." (Big Lebowski)
Good to see some things fixed here.
This is a really nasty topic, Linux-Linux but also in exchange with other OSes and files systems. If you just want to make a backup some userspace programs set all directory time stamps as created/modified today (2022) instead of keeping the old timestamp. Or, if you open a file in a directory a write process is started (.lock files, mini-swaps, backups and the like) and voila the time stamp of the directory changes and is messed up.
So therefore more stable and correct timestamp handling would be neat.

[Nth_man]

Also from... 2014 (!) :

"modern filesystems on Linux such as EXT4 and BTRFS also support a file creation timestamp."
-- http://blog.fpmurphy.com/2014/06/fil...e-in-ext4.html

[Nth_man]

Like someone asked:

What exactly would “creation date” mean, though? If I do

cp -a file1 file2

should file2 be given the same creation date as file1? Or should it be given a creation date of now?

[Nth_man]

Creation time will still be usable only for a specific niche. On UNIX, it is common to replace a file instead of rewriting it. It is atomic and open files will not stop you from replacing it. It is the case for software updates but it might also happen with many more tools. For example, "sed -i" will create a new file, write the output and replace the original one.

" > I am trying to read a file which has several lines of data, modify [...]

Modifying a file at a specific location is tricky. Generally it's much easier to create a new file, copying lines from the original file and changing as needed, and then rename the new file to the original name when you're done."
-- https://stackoverflow.com/questions/...-file/56531548

[luizluca]

Creation time will still be usable only for a specific niche. On UNIX, it is common to replace a file instead of rewriting it. It is atomic and open files will not stop you from replacing it. It is the case for software updates but it might also happen with many more tools. For example, "sed -i" will create a new file, write the output and replace the original one.

[George99]

It is insane how Linux even today in 2022 does not have support for creation date information for files, other operating systems have had this functionality for decades.

Well it does have support but not for FAT right now.

stat mbox
File: mbox
Size: 9372 Blocks: 24 IO Block: 4096 regular file
Device: 805h/2053d Inode: 29099467 Links: 1
Access: (0600/-rw-------) Uid: ( 1000/ _user_) Gid: ( 1000/ _user_)
Access: 2022-04-23 08:59:11.329221639 +0200
Modify: 2022-04-14 14:02:48.159957564 +0200
Change: 2022-04-14 14:02:48.159957564 +0200
Birth: 2022-02-11 03:50:10.975526182 +0100

[fld-]

I understand that creation time is cool yes it has its uses, and I want it there too, but really - what real world use does it have?!

Because sometimes you want directories listed in the order they were created, instead of having the order change every time you modify something within those directories

[waxhead]

It is insane how Linux even today in 2022 does not have support for creation date information for files, other operating systems have had this functionality for decades.

I understand that creation time is cool yes it has its uses, and I want it there too, but really - what real world use does it have?!

You already got modification date and when you modify a file it is not equal to the original and therefore a new file.

Ergo the modification time is identical to when this "new" file was created so why would you need the date of a non-existing file which really is what this is when you think about it?