LinuxQuestions.org
Support LQ: Use code LQ3 and save $3 on Domain Registration
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 02-21-2015, 03:53 PM   #1
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Rep: Reputation: Disabled
Create Date


Someone told me there is no such thing as a (file) "created_on" date in Linux...
 
Old 02-21-2015, 04:37 PM   #2
GNU/Linux
Member
 
Registered: Sep 2012
Distribution: Slackware-14
Posts: 118

Rep: Reputation: Disabled
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 (-).
 
Old 02-21-2015, 04:46 PM   #3
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,654

Rep: Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255
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.
 
Old 02-21-2015, 04:51 PM   #4
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by GNU/Linux View Post
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 (-).
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
 
Old 02-21-2015, 05:48 PM   #5
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,654

Rep: Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255
Quote:
Originally Posted by RobInRockCity View Post
What percentage of Linux computers out there use the "newer" flavors which support this?
None that I know of
Quote:
And any guess why in the world anyone would design an op sys without storing the created_on of files??


Rob
Of what use is the creation date?
 
Old 02-21-2015, 05:59 PM   #6
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by jpollard View Post
None that I know of
ext4 supports creation_date


Quote:
Originally Posted by jpollard View Post
Of what use is the creation date?
Right.
 
Old 02-21-2015, 06:22 PM   #7
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,654

Rep: Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255
Quote:
Originally Posted by RobInRockCity View Post
ext4 supports creation_date
I believe early plans were for ext4 to also support file versions. But no consensus on how to do that was ever reached.
Quote:
Right.
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).
 
Old 02-21-2015, 06:44 PM   #8
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Original Poster
Rep: Reputation: Disabled
jpollard,

Thanks for the reply!


Quote:
Originally Posted by jpollard View Post
I believe early plans were for ext4 to also support file versions. But no consensus on how to do that was ever reached.
According to this it does exist, if by another name.


Quote:
Originally Posted by jpollard View Post
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.
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?)



Quote:
Originally Posted by jpollard View Post
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.
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.


Quote:
Originally Posted by jpollard View Post
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).
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

Last edited by RobInRockCity; 02-21-2015 at 06:47 PM.
 
Old 02-21-2015, 07:10 PM   #9
astrogeek
Moderator
 
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=14, FreeBSD_10{.0|.1|.2}
Posts: 4,009
Blog Entries: 1

Rep: Reputation: 2110Reputation: 2110Reputation: 2110Reputation: 2110Reputation: 2110Reputation: 2110Reputation: 2110Reputation: 2110Reputation: 2110Reputation: 2110Reputation: 2110
Quote:
Originally Posted by RobInRockCity View Post
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!!)
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...

Quote:
Originally Posted by RobInRockCity View Post
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?)
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!

Quote:
Originally Posted by RobInRockCity View Post
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!!!!!
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!

Last edited by astrogeek; 02-21-2015 at 07:16 PM. Reason: typos, small changes to text
 
Old 02-21-2015, 07:19 PM   #10
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by astrogeek View Post
Well, IMO what really is crap is cPanel's file manager! And it definitely is not a version control system!
I am starting to see that...


Quote:
Originally Posted by astrogeek View Post
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...
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

Last edited by RobInRockCity; 02-21-2015 at 07:21 PM.
 
Old 02-21-2015, 07:23 PM   #11
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,654

Rep: Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255
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/

Last edited by jpollard; 02-21-2015 at 07:33 PM.
 
Old 02-21-2015, 07:51 PM   #12
RobInRockCity
Member
 
Registered: Feb 2015
Posts: 141

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by jpollard View Post
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.
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...


Quote:
Originally Posted by jpollard View Post
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).
And as far as I know, that is how Windows and OS-X has done it.


Quote:
Originally Posted by jpollard View Post
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).
For my needs that is probably sufficient.


Quote:
Originally Posted by jpollard View Post
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).
Not very well!


Quote:
Originally Posted by jpollard View Post
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.
Fair enough.


Quote:
Originally Posted by jpollard View Post
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/
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
 
Old 02-21-2015, 09:13 PM   #13
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,654

Rep: Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255
Quote:
Originally Posted by RobInRockCity View Post
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...
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.

Quote:

And as far as I know, that is how Windows and OS-X has done it.
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.

Quote:
...

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!!
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.
 
Old 02-21-2015, 09:17 PM   #14
Doug G
Member
 
Registered: Jul 2013
Posts: 650

Rep: Reputation: Disabled
Just to chime in, the lack of file creation date metadata is one of the things I really miss with linux filesystems.
 
Old 02-21-2015, 10:08 PM   #15
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 3,116

Rep: Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
create a file with the date included. Springs Linux - Newbie 10 11-27-2012 03:12 AM
[SOLVED] Script to create new directory with date moyorakkhi Linux - Newbie 3 04-22-2011 04:14 AM
script to create directory with date thetiger2003 Linux - Newbie 3 12-06-2010 05:40 AM
[SOLVED] Use date with touch to create new file with date based name craigjl Linux - Newbie 5 03-12-2010 10:46 AM
I want to create user who has right to change the date manoj.linux Linux - Enterprise 3 08-16-2007 05:43 PM


All times are GMT -5. The time now is 12:57 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration