For Linux there is "touch" for modified and accessed times. Some systems support created at times and/or changed at times. I know "debugfs" with "set_inode_field" is a common way to set those timestamps. It is a Linux debugger system and unsafe for regular use. How many of you would like feature of a safe way to set inode data such as all timestamps? Feel free to tell your Linux distro developers if you do want it. As of now there is only "debugfs" and "touch" for that. Good uses would be like from Windows or other systems that support created at or changed at or backups and restore without system images. Do not expect Linux that you do not control to be like this any time soon but would you prefer it? I realize there is rsync now and -N for created at. Never seen a changed at setter other than debugfs. POSIX compliance means all Linux has changed at so you have that and what touch can set. X E.

This is a very weird poll!

The tools available already allow us to manipulate all Linux File System timestamps (although some easier than others) and that is all we need.
I would not WANT Microsoft style time stamps on my Linux systems, and that is where this gets you if you pursue it to the logical conclusions.

Just "NO"!

1 members found this post helpful.

Not all safely but most. Changed at is not safely settable on a running system and neither is created at according to what I know. If you want to change what I know feel free though. X E.

crtime (birth/creation) tells when a free inode was taken into use and ctime (change) tells when the inode data was last changed. If you copy a file (cp -p / tar / rsync -a) to the same file system or to a backup disk, you use another inode, and crtime and ctime will be new. Or if you edit an existing file, your editor typically creates a new file (using another inode) for the edited text and finally renames the file name in the directory to the old name. So, the file will have a different inode and a different crtime. crtime does not mean when the text document was originally created but when the inode was taken into use where the file content now is. If you back up your files and restore, you use new inodes with new inode numbers and they should have new crtime. (An exception is if you do an exact bit copy of the file system. Then the files will use the original inodes, of course.)

Why would you want to change crtime and ctime? They don't affect anything. mtime is useful: it's THE file date, preserved by tar and everything. atime is also useless nowadays. Because of the adverse effect on performance, everything is mounted with noatime.

It's the kernel developers who have decided userland should not have write access to inode ctime/crtime.

1 members found this post helpful.

I like to lose nothing upon restores and I use crtime to know when I started working on stuff. X E.

Well, I can't delete this but I assume all or most votes going forward will be no so can like a moderator or something just delete this? I was posting this because I thought it was outragous that that command does not exist on much of Linux including mine. X E.

I timestamp my projects. IT can be as easy as in my project folder.

My EOD script has a line likeline to record my time.

I can easily code a script to extract the active work times and generate daily and weekly totals for hours, minutes, and seconds (or hours decimal) on the project.

Nice. X E.