Thunar and 'ls' or 'stat' agree on atimes for files, but not for directories, why is that? The times listed by Thunar seem more believable, but if the atimes are not from wherever 'stat' gets its information, then where are they from? And what exactly does constitute an atime event for a directory anyway? Listing the contents of the dir doesn't do it, so what does? As far as 'ls -lu' is concerned, even writing a file to a dir doesn't change it's atime, yet they do change now and again. What gives?
Further to that, a reboot and restart of xfce/thunar fixes the problem, now thunar agrees with stat, however, previously, hitting the 'reload current folder' did NOT repair the listing, as I'd have expected it to, if there was obsolete information. Could this be a bug?
From man 2 stat:
Not all of the Linux file systems implement all of the time fields.
Some file system types allow mounting in such a way that file and/or
directory accesses do not cause an update of the st_atime field. (See
noatime, nodiratime, and relatime in mount(8), and related information
in mount(2).) In addition, st_atime is not updated if a file is opened
with the O_NOATIME; see open(2).
I remember reading on the Linux Kernel Mailing List a whole bunch of discussions on atime. It appears that kernel developers and filesystem developers have different viewpoints. So, I would guess it is normal behavior for the filesystem you are running. A good question. Glad you asked it. I'll certainly hope others with more knowledge of thunar chime in.
I have read a fair bit on this. As you say, the whole subject seems to be a bit of a mess. For the record, all my FS are ext4 and I have no 'noatime' or any other such tinkerings in my fstab, it's all plain vanilla. Anyway, the point is, that it would seem to me that Thunar should report the same as 'stat' reports, however useful or not that date is or isn't. And note that there was no issue with files, only with directories (folders, in Redmond speak), so that would seem to be a bug. However, it seems strange that Thunar would or even could somehow come up with some other source for atime--where would these dates/times possibly come from?--so either way, it's a mystery.
Here's a current example.
'ls -lut': Thunar:
drwxrwxrwt 14 root 116K Dec 19 08:26 tmp/ 2013-12-18 20:09:52
drwxr-xr-x 2 root 4.0K Dec 19 08:16 bin/ 2013-12-18 07:35:06
drwxr-xr-x 12 root 0 Dec 18 20:14 sys/ 2013-12-18 20:06:57
drwxr-xr-x 19 root 620 Dec 18 20:14 run/ 2013-12-18 20:06:57
Again, hitting the reload button does not fix it, but a reload of Thunar *does* fix it.