LinuxQuestions.org - Is there some special reason that Windows can tell you a file's creation time, but Linux generally does not?

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - Is there some special reason that Windows can tell you a file's creation time, but Linux generally does not? (https://www.linuxquestions.org/questions/linux-newbie-8/is-there-some-special-reason-that-windows-can-tell-you-a-files-creation-time-but-linux-generally-does-not-4175735348/)

Not seeing birth date over sshfs is because sftp does not have the capability. sshfs is technically not a filesystem.

Short answer is that only some Linux filesystems even have that field AND only some tools(!) have been amended to read/write it - or not ...
;)

A classic real world example of the acronym YMMV :)

I just ran stat on a file and got this weird result:

Code:

$ stat images/buttonbar.gif

  File: images/buttonbar.gif

  Size: 4568            Blocks: 16        IO Block: 4096  regular file

Device: 8,3    Inode: 130396      Links: 1

Access: (0644/-rw-r--r--)  Uid: ( 1000/  hazel)  Gid: (  100/  users)

Access: 2024-03-28 06:04:20.479987736 +0000

Modify: 2014-01-03 16:35:02.000000000 +0000

Change: 2023-10-26 06:44:21.812929003 +0100

 Birth: 2023-10-26 06:44:21.811929003 +0100

As you can see, there is a Birth date given but it's a really silly one. Compare it with the Modify date, which looks appropriate to me.

there was a link in post #9. It is practically useless, not in use, not supported everywhere and also in most cases meaningless.

The truth is that NO system can tell you the birth time of a file, they can only report the data field as stored in the metadata for that file. The file metadata can be, and often is, wrong. We have tools to manipulate it if we want to MAKE it wrong. Why would you trust that?

Quote:

Originally Posted by hazel (Post 6492443)

As you can see, there is a Birth date given but it's a really silly one. Compare it with the Modify date, which looks appropriate to me.

It's not "really silly", it's potentially useful information.

It tells you the file arrived on your system a few months back, but the data within the file probably has not been modified for a decade.

Yes, both of those values can be spoofed, but have they been? If you haven't done it yourself, and your system hasn't been compromised, how likely is it...?

Quote:

Originally Posted by boughtonp (Post 6492542)

The problem is that you will never know the truth. I mean why is it set, how is it set and when was it set.

Quote:

Originally Posted by boughtonp (Post 6492542)

It's not "really silly", it's potentially useful information.
It tells you the file arrived on your system a few months back, but the data within the file probably has not been modified for a decade.

Would that be when I transferred my data from the old hard drive to the new one?

Quote:

Originally Posted by hazel (Post 6492557)

Would that be when I transferred my data from the old hard drive to the new one?

Possibly. Depending upon how you did it and what might have smudged the metadata for that file since then.

Personally, I keep a continuity document for each of my servers recording the hardware configuration, firmware level, significant changes and the dates of those changes, major software configurations and change dates. For a change I do a change document with reasons, expected benefits, expected behavior, test plan, and a backout plan in case things go south. (For trivial change this is a couple of paragraphs, for major changes 9rare, very rare) it can be 5 or 6 pages.

These are well practiced and less involved then the Official ones I learned to do for the companies I worked for. Those took approvals form another sysadmin, a supervisor, an operations of client supervisor, and were 5 to 12 pages EVERY DANG TIME! Yeah, I do not run anything that requires that much headache at home.

The thing is that the machine can be wrong, it can lie, but I have a journal where I can look it up if it really matters. That has literally saved lives (and my job) on occasion, and made recovery from failures of home hardware just frustrating instead of impossible.