Create Date
 

Someone told me there is no such thing as a (file) "created_on" date in Linux...

Some filesytems (Btrfs, ext4) do support the create date, but Linux kernel does not provide a way to implement it. You can run 'stat' command on a file to see what's next to 'Birth'. Usually it's just a dash (-).

Yeah... creation dates have not been all that useful. The "creation date" became "inode modification date", which recorded when file access modes were last changed.

The 'creation date' becomes useless when the entire contents of a file can be replaced... yet the creation date would remain...

Creation date was useful... but only on systems that supported file versions. In that case, even if you replaced the contents you would normally get a new version - thus the original data would still remain, and the date would make sense.

What percentage of Linux computers out there use the "newer" flavors which support this?

And any guess why in the world anyone would design an op sys without storing the created_on of files??


Rob

None that I know of
Of what use is the creation date?

ext4 supports creation_date


Right.

I believe early plans were for ext4 to also support file versions. But no consensus on how to do that was ever reached.
Which why I asked. There may be some use - but as I said, with a file that can have its entire contents replaced, what use is the creation date? All it does is identify when the inode was allocated. It can't say anything about the data.

I have worked with filesystems with multiple dates (VMS):
creation date - when the file version was created...
modification date - when the file was last updated...
backup date - when the file was backed up, and null if not backed up.
accessed date - when the last access occurred.

The most useless was the creation date - unless there was a file version information with the file, it was useless - especially if the file had its contents replaced, which would show only a modification date. Updates to binary data files made it useless.

I have even worked with one that included "restored date" (a data migration system, the restored date would be more recent than the modification date, unless the data was later modified - in which case the backup date would be earlier than the modification, indicating the file needed to be archived... again. But if there is a creation date, then there would also have to be a metadata "changed" date (to record when things like access permissions changed)

Right now, "creation date" field is also used for "inode changed" (as the inode changed when it got initially allocated and initialized).

jpollard,

Thanks for the reply!


According to this it does exist, if by another name.


Here is what created my inquiry...

Today I was learning cPanel's File Manager, and went to copy my web host's original Web Root files to a new folder called "z_webhost_orig"

When I did this in cPanel, the "copy" changed all of the "modified_on" dates to now. (I have never seen that in the Windows or Mac worlds, and think that is crap!!)

So it got me to thinking, "If there was a created_on date I could see, then even if the modified_date gets molested, I can still use created_on to verify which files are the originals and which are clones/copies.

What I would really like to know are these things...

1.) Can I make cPanel File Manager not screw with the modified_date when all I did was make a copy of a file - which is NOT modifying it by most people's standards.

2.) Can I show created_on in cPanel's File Manager if I can't achieve #1?

3.) Is there a created_on property associated with Linux files? (Sounds like the answer is, "It depends on the flavor." (Do you know what CentOS 6 does?)



If I have config.txt with created_on and modified_on dates, and I modify it, then those dates no longer match telling me I modified it. The created_on date also lets me know - you guessed it - when the file came to being. Which is useless in what I was doing today. (When did my web host originally create this file?)

If a file changes, that is why there is a modified date. People still want to know when the file was originally created - similar to versioning via timestamp.


If cPanel wasn't a PITA and did what Windows and Mac and what sensible people would expect - don't screw with modified date when you make copies or backups of files, then I wouldn't care about created_on.

If I make a manual copy or backup 10,000 files - with varying creation_dates - why in God's name would I want everything changed to now??

You lose ALL of the files' history!!!!!

Sincerely,


Rob

Well, IMO what really is crap is cPanel's file manager! And it definitely is not a version control system!

You are trying to use a mangled and crippled web interface for a common filesystem task and version control system, and blaming the underlying filesystem for the perceived shortcomings!

If cpanel does not offer the option to preserve the original file meta-data, including modified dates, then simply login
via SSH and use cp -rp /src /dest, which will do what you are asking.

Right tool for the job... ;)

I doubt you would find such consensus on "most people's standards", it is really just "what I want!".

As jpollard has pointed out, the creation date is defined as inode modified time, and when you make a copy, you are creating a "new" file in the destination location, modifying those new inodes, so setting the date to now seems pretty dang sensible for "most" purposes.

However, the cp command allows you to keep the same dates and permissions as the original if you want, with the -p option. The fact that cPanel does not pass that option up to the user is a cPanel shortcoming, not a Linux fault!

Well, as noted, the creation date of the copies is the date the copies were made - and the filesystem is not intended to be a version control system which retains all of a file's history!

I am starting to see that...


Good idea.

Could you swing by my thread on that exact topic located here...

I would like to learn how to do at least some things by command line, but first I need to understand how to do that from my MacBook to my VPS.

Sincerely,


Rob

Copying a file normally has to modify the copied file... It also has to "create the file" as the target of the copy - it is a new file...

A copy does not change the source file (other than an access time)...

But making a copy HAS to create a new file. And that new file has a new creation date.

Now certain backups (such as tar) put the "copy" in an archive file. The dates recorded in the backup are those of the orginal file (as the copy is embedded in a new file, thus the metadata can also be recorded).

The cp (cp -p option) utility CAN preserve modification date and access dates. But it cannot preserve the creation time (as the new file has to have a new inode - and it gets a new date). The rsync utility can also do that (rsync -t option).

How the GUI does a copy I don't know (hate those things - with me they screw up as often as they do things right, and the configurations are never sufficiently detailed to get what I want).

One reason users can't prevent the inode modification date/creation date from being changed has to do with security audits. It prevents creating a file in the past... which could then pass file system checks for nefarious purposes. Only access time and modification time can be manipulated.

One last note - There is a version control filesystem (gitfs) that accepts copies of files and creates a time stamped log of every change to a file. The timestamps are those of when the copy into the filesystem was done... But it is an interesting project, but I don't think it is meant to be used as a live filesystem - just one that is a git version control system.
http://www.presslabs.com/gitfs/docs/

I can sort of see it that way, but if you are copying a file, the modified_on timestamp should not change because you aren't touching the file contents or meta-data...


And as far as I know, that is how Windows and OS-X has done it.


For my needs that is probably sufficient.


Not very well! ;)


Fair enough.


Thanks, I will check it out.

Now is probably also a good time for me to finally break down and learn how to use application development tools like Subversion, although that wouldn't apply here, because I am trying to preserve a record of the files my web host originally installed on my VPS.

The only way to do what I want in the GUI would be to MOVE everything to my backup folder - thus preserving all file meta data - and then create new versions of each file and copy the contents of the originals into the new files. What a PITA!!

Of course if I can get some more help in my other thread, maybe I will eventually learn how to use SSH to do more power stuff using command line?! :)

Sincerely,


Rob

Actually, you are - the filesystem cannot tell whether what is being done is a "copy", or the creation of a new file. That is why cp has the -p (preserve) option. What happens is that the file is copied, gets a new access and modification... then cp resets the access and modification dates.

And that would be why the contents of those files show original dates for the data associated with that file. But the containing file will have current dates.

It will depend on WHERE the move destination is. If it is on the same filesystem, then a move just changes pointers to the inode (the changes are strictly to the directory, which gets the changes to the access and modifications dates :), thus no changes to the date. If it is to a different filesystem, then it makes a copy... and deletes the original files.

Just to chime in, the lack of file creation date metadata is one of the things I really miss with linux filesystems.

The ext4 filesystem has creation time, and it's supported in the kernel. I can use debugfs to stat the inode and see crtime, but I don't know of any other tools that do anything with it.