Okay so I know there is "touch" and "debugfs" with "set_inode_field" for setting timestamps. First can anyone check if debugfs actually can set crtime and ctime (created at and changed at)?
crtime:
https://zzzcode.ai/answer-question?i...b-909627aff1d8
ctime (replace ctime with crtime for crtime):
https://zzzcode.ai/answer-question?i...5-3422a295e7c7
That syntax is like:
sudo debugfs -w -R "set_inode_field $inode ctime $dateInSeconds" /dev/sda1
For crtime:
sudo debugfs -w -R "set_inode_field $inode crtime $dateInSeconds" /dev/sda1
Accessed at time:
touch -a -d access_time file_path
Modified time:
touch -m -d access_time file_path

With those commands, maybe just second zzzcode thing with stat for inode, what order should I restore to get all values for timestamps set? Also, does debugfs actually set created at time and changed at time? NOTE: DEBUGFS IS NOT FOR "REGULAR USE", BE CAREFUL. debugfs REQUIRES sudo or root. I am on an Ubuntu desktop 22.04.3 with Ubuntu Pro Lenovo Thinkpad T460. These commands are for Ubuntu. All as per one might be maybe or might not be maybe, maybe or maybe not, maybe.

Is there a point to this and the many similar questions asked??? Why are you setting inodes manually?? Your backups don't care about dates/times/inodes....they just write the restored data back to the disk.

What's the point of all this?? What are you trying to accomplish, other than annoying everyone with the "maybe, maybe not" junk??

I am trying to have a full backup that I can use without bootable stuff. Since Linux does not have a common use way to restore all timestamps I was trying debugfs. Purpose of this one is so I can properly restore timestamps I already stored for restoration purposes. I do not want to set any other inode data with this. Setting which inode as before restoration would be even better but Linux probably won't support that in near future. Anyway almost all like my questions are about how to have a full, not excluding anything that can not be excluded, backup. Sorry if I am annoying, I just do that ending. Also, I want to be as sure as I can be that all is backed up. I know there is Clonezilla now but have not used it because I do not know if it backs up all that can be backed up. All as per one might be maybe or might not be maybe, maybe or maybe not, maybe.

There is ZERO need to restore timestamps, and there are MANY Linux utilities you can use to create bootable, restorable system snapshots. Mondoarchive is one, rescuezilla, and a host of others. And there is no need to back up your entire root filesystem...back up your config files for the services and reload the OS if you need to. Back up your home data using something as simple as a "cp" command (and rsync, as you've been told) to whatever media you have. Again, no need to do any of this. Searching this site for backup solutions brings up loads....putting "how to back up a Linux system" into Google will ALSO give you lots. You name one utility, but apparently haven't tried it so there's little point in asking repeatedly until you test what you want to find any problems.

And if you know you're being annoying wit the "maybe, maybe not" stuff, and you're getting TOLD it's annoying and you continue anyway, you're obviously trolling and/or plain rude. We volunteer our time here and if you keep annoying folks knowingly, don't be surprised if you get no help. And there's no 'maybe' about that.

Yes there is imaging stuff. Not having restored from all of it before I cannot say if it actually restores everything everything or some portion only. Since stuff like debugfs is not well known I doubt any of it actually restores all timestamps. I guess I could try to ask companies that make backup solutions but user with experiences is better I think. Also, I have two ways to write, either all questions (even more annoying according to Stack Exchange) or just an ending you can ignore if you want. Not trying to troll or anything like that. I am trying for an everything everything backup and do not know yet what each tool actually backs up. Also, timestamps are important to me to have whether in your opinion they are not or not. Again, sorry if it annoys you but it is just what I do. All as per one might be maybe or might not be maybe, maybe or maybe not, maybe.

Then why aren't you paying attention to the answers/advice you're getting??? Again: debugfs, timestamps on inodes, etc., are *MEANINGLESS* for backups. Copy your data to some other media, and put it in a safe place. You now have a copy of your data. Do this as often as you like, with any utility you like from as simple as an rsync, to a genuine versioning backup utility. Pick one.
They are not important, no matter what you think. If you're a new user and you're asking experienced users for advice and ignoring it, why bother asking???

Again, you're 'Maybe, maybe not' junk is plain irritating. You make a conscious choice to do it, despite being asked not to.

Can you answer me this? Is there documentation for any cloner that says it restored all timestamps? If not I could make a program with this easily and share maybe or maybe not, maybe.

https://zzzcode.ai/answer-question?i...2-26040c74d114
According to that, created at, changed at, modified at, accessed at times is correct order. Not tested but I will accept this. With that, debugfs first, touch second. I asked it several different ways and it consistently gave this order. Use untested at your own risk. All as per one might be maybe or might not be maybe, maybe or maybe not, maybe.

I just realized to put $inode in <> so actually like this:
debugfs -w -R 'set_inode_field <'$inode'> crtime '$formatted_time'' "$device"
Also like this for changed at time:
debugfs -w -R 'set_inode_field <'$inode'> ctime '$formatted_time'' "$device"
Sorry I do not know this thing much now. X E.

https://unix.stackexchange.com/quest...4fs-filesystem
Do not do this on a main file system, use a bootable USB. X E.

I read that inode changed time is last time meta data changed so not that order. I think instead created at, modified at, accessed at, changed at. There is debugfs for all those timestamps. I read changed at is when meta data last changed so that can't be other than last. Also, fields may be i_crtime and i_ctime according to zzzcode.ai. I am confused now. X E.

I would not trust AI for any answers.

Have you looked at the inode table structure to see what names are for time? At bit out of date but should be valid for what you seek.

https://ext4.wiki.kernel.org/index.p...ut#Inode_Table

Something to consider is that debugfs is only for ext2/ext3/ext4 file systems.

I agree with that do not trust AI mostly, but for suggestions maybe. Anyway, set_inode_field -l should list all fields. I just can't use it. I know letters for times, crtime, ctime, mtime, atime. With something as crucial as this, do not trust completely an AI but when no information available, try anything that may know more. According to zzzcode.ai now just add "i_" before those for fields. X E.

I skimmed it. What I really could use is output of set_inode_field -l. That and how to set with nanosecond precision like on like my operating system. I know like my system is ext4. Got any more useful stuff? I already contacted Theodore Ts'o because there is little information on web. zzzcode contradicts itself a lot on this subject. I have seen ending like MM:SS, unsure whether I could add .nanos. Research to do and no actual material to study. I know that created at time can be set with this with research from a real person. They had it with hi and lo. debugfs is cross platform some so any set_inode_field -l would help. That is from man debugfs so I know I can trust that. X E.

I think what you mean is that debugfs is linux distribution agnostic but only for ext2/3/4 filesystems.

It looks a bit more complicated with the extra bits for years>2038. Previously I believe you could use crtime for seconds since epoch and crtime_extra sub-second precision. Now there is i_crtime and and I_crtime_extra. There are examples of changing the other timestamps but crtime not so much. As posted for most people crtime isn't necessary to preserve.

1 members found this post helpful.