OS timestamps
-
Hello,
thank you for the reply
I use version 5.15.0 of Qt on Ubuntu 18.04.5 LTS
for deleting the folder on the command line:
rm -r dir/For deleting the folder with Qt:
QDir dir(path_directory_to_delete);
bool isDelete = dir.removeRecursively();
Q_ASSERT(isDelete);thanks
-
Hi,
@JonB Though not specified by POSIX, Linux on EXT4 and FreeBSD on UFS2 store the date of creation (B).
-
Hi,
@JonB POSIX specifies MAC timestamps:
Each file has three distinct associated timestamps: the time of last data access, the time of last data modification, and the time the file status last changed. These values are returned in the file characteristics structure struct stat, as described in <sys/stat.h>.
Data access (A) is when the file data is read, data modification (M) when the file data is modified, and file status changed (C) when the file metadata is changed (chown, chmod, new hardlink updating the link count…).
-
Hi,
@JonB POSIX specifies MAC timestamps:
Each file has three distinct associated timestamps: the time of last data access, the time of last data modification, and the time the file status last changed. These values are returned in the file characteristics structure struct stat, as described in <sys/stat.h>.
Data access (A) is when the file data is read, data modification (M) when the file data is modified, and file status changed (C) when the file metadata is changed (chown, chmod, new hardlink updating the link count…).
@ted19b
Sorry I do get MAC, as per stat. What I am not understanding is what your B is and how it differs from C? Is it that the extra B remains fixed as date of creation, while C varies a bit more? TBH I didn't know C changed from e.g. chown, I thought C was your B.... -
@ted19b
Sorry I do get MAC, as per stat. What I am not understanding is what your B is and how it differs from C? Is it that the extra B remains fixed as date of creation, while C varies a bit more? TBH I didn't know C changed from e.g. chown, I thought C was your B....sorry for the late reply. Indeed that's the idea. The B records the date of creation of the file and it doesn't change anymore.
While the C is updated according to the operations we can perform on the file.
for example: we have a tmp.txt file in a src/ folder.
copy this file to a dst/ folder will update the C timestamps of the src/ folder -
sorry for the late reply. Indeed that's the idea. The B records the date of creation of the file and it doesn't change anymore.
While the C is updated according to the operations we can perform on the file.
for example: we have a tmp.txt file in a src/ folder.
copy this file to a dst/ folder will update the C timestamps of the src/ folder@ted19b
Thanks for all this information. I am old-time Unix user(!), very familiar with the MAC timestamps, never heard of your B one.So, please help: I am Ubuntu.
lsblk -fsays my disk isext4. I don't see an option tolsto display this B stamp, and what system call (likestat) accesses it, please? -
@ted19b
Thanks for all this information. I am old-time Unix user(!), very familiar with the MAC timestamps, never heard of your B one.So, please help: I am Ubuntu.
lsblk -fsays my disk isext4. I don't see an option tolsto display this B stamp, and what system call (likestat) accesses it, please? -
I think this article contains the answers to all your questions.
https://www.sans.org/blog/understanding-ext4-part-2-timestamps/
@ted19b
Thanks for this. My Ubuntu 20.04'sstatis still one version too old to report this B. I didn't want to download anything, I useddebugfs -R 'stat <'`stat -c %i /etc/profile`'>' /dev/sda5to see the Birth/crtime. Don't know what you use. Very interesting.
Anyway, I imagine like I said you'll want to look at the source code I referenced to follow its behaviour. I admit that glancing I can't see why parent would have its B/crtime changed, presumably that should only happen when something is created and I can't see that. I'd be interested to hear if you analyze/debug the code why that is occurring!
-
finally after analysing the implementation, the result is rather what I was hoping for, namely
parent_dir/ shows that the MC timestamps have been updated.
This means that the problem certainly comes from my code.
thank you all.
For those of you who may be interested in timestamp analysis, especially in the field of security, I think this article may be of interest to you.
-
finally after analysing the implementation, the result is rather what I was hoping for, namely
parent_dir/ shows that the MC timestamps have been updated.
This means that the problem certainly comes from my code.
thank you all.
For those of you who may be interested in timestamp analysis, especially in the field of security, I think this article may be of interest to you.
@ted19b
I'm the person who's interested in this :) Thanks for all your replies/links.This means that the problem certainly comes from my code.
Glad you have discovered this. When I looked at the https://code.woboq.org/qt5/qtbase/src/corelib/io/qdir.cpp.html#_ZN4QDir17removeRecursivelyEv implementation I could only see it doing non-creationtime operations, so your findings now correspond :)
