OS timestamps

[ted19b]

Hi,

Suppose we have a folder named dir/ in a folder named parent/

After deletion of the dir/ folder in a terminal command line. Analysis of the timestamps of the parent/ folder reveals that the M and C timestamps have been updated.

When deleting the same folder dir/ with Qt's removeRecursively function for deleting a folder. Analysis of the timestamps of the parent/ folder shows that the MACB timestamps have all been updated.

Is there a reason for this behaviour?

Especially when we know that for most other Qt functions operating on files, the modification of timestamps is similar to that of the terminal utilities.

Thanks for help

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