OS timestamps

SGaist

Hi and welcome to devnet,

Which version of Qt ?
On which OS ?

Can you show the code you are using as well as the command ?

There might be some subtle difference.

ted19b

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

JonB

@ted19b
Well you can see the implementation at https://code.woboq.org/qt5/qtbase/src/corelib/io/qdir.cpp.html#_ZN4QDir17removeRecursivelyEv

What is a B timestamp?

ted19b

Hi,

@JonB Though not specified by POSIX, Linux on EXT4 and FreeBSD on UFS2 store the date of creation (B).

JonB

@ted19b
In that case, could you explain what the C timestamp is, and how that differs from the B one? M is Modification, A is Access, C is creation and B seems to be Creation too? I am interested :)

ted19b

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…).

JonB

@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

@JonB

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

JonB

@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 -f says my disk is ext4. I don't see an option to ls to display this B stamp, and what system call (like stat) accesses it, please?

ted19b

@JonB

I think this article contains the answers to all your questions.

https://www.sans.org/blog/understanding-ext4-part-2-timestamps/

JonB

@ted19b
Thanks for this. My Ubuntu 20.04's stat is still one version too old to report this B. I didn't want to download anything, I used

debugfs -R 'stat <'`stat -c %i /etc/profile`'>' /dev/sda5

to 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!

ted19b

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.

https://medium.com/@quoscient/mac-b-timestamps-across-posix-implementations-linux-openbsd-freebsd-1e2d5893e4f

JonB

@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 :)