Display of Parent Directory Date

[jiangzhenjerry]

Hello all,

I would like to take this opportunity to mention something that has puzzled me for a long time, at least since 9.51. It's related to the display of parent directory date in the default "full" view. I will use two examples to describe it - and the logic of the two examples somehow contradicts with each other. To me it seems almost like a bug, but it could also be by design.

Notes:
1. I have always been on the Windows Insiders Build, and as I mentioned, this "issue" (may not be) has occurred ever since 9.51 with the latest Windows 10 preview.
2. I try to write out everything I see in the file list panel, but you can also refer to the screenshots here (numbered) for better visualization.

Example 1

Let's say I navigate into the folder D:\Downloads\Total Commander, and it looks like below (and can be seen in Screenshot 1 in the link above):

Code: Select all

D:\Downloads\Total Commander\
----------------------------------------------------
..		<DIR>	2018-12-14 09:07	----
1 Program\	<DIR>	2021-05-06 10:32	----
2 Settings\	<DIR>	2021-05-06 10:00	----
3 Plugins\	<DIR>	2021-04-10 02:21	----
4 Icons\	<DIR>	2016-05-26 01:04	----
5 Documents\	<DIR>	2020-10-09 05:46	----

Guess which folder does the date in the first line (2018-12-14 09:07) refer to? For some reason, my intuition always tells me that it is the date of the current folder, i.e., Total Commander, probably because of the way the information is displayed. But no, the date of Total Commander is actually (Screenshot 2)

Code: Select all

Total Commander\	<DIR>	2021-05-06 10:00	----

In fact, 2018-12-14 09:07 is the date of D:\Downloads, i.e., the parent folder of Total Commander (Screenshot 3):

Code: Select all

Downloads\	<DIR>	2018-12-14 09:07	----

OK, I think I can try hard to adapt myself to it, because technically ".." in this case does mean "D:\Downloads".

Example 2

Let's look at a different example, where I navigate into D:\Downloads, and it looks like (Screenshot 4)

Code: Select all

D:\Downloads\
----------------------------------------------------
..		<DIR>	2021-05-07 00:11	----
[Apps]\		<DIR>	2021-05-04 01:47	----
7-Zip\		<DIR>	2021-05-06 00:11	----
aria2\		<DIR>	2019-10-05 18:43	----
Audacity\	<DIR>	2021-04-19 03:48	----

(rest omitted)

Now guess which folder does the date in the first line (2021-05-07 00:11) refer to? Based on the logic from the previous example, it should be the parent folder of D:\Downloads\, which is... D:\ ??? Well, D:\ doesn't have a date, so the date seen here is actually the date of the recycle bin (Screenshot 5):

Code: Select all

D:\
----------------------------------------------------
$RECYCLE.BIN\	<DIR>	2021-05-07 00:11	--hs

Edit: @umbra reminded me that D:\ does have a date, and what's displayed under D:\Downloads\ is indeed the date of of D:\. In this specific example, the date of D:\$RECYCLE.BIN\ happens to be the same as D:\, which misled me a bit.

I find my mind always spends quite a bit of time to digest the number I see in here, so my workaround is to use a custom columns view, in which the date in the first line is always empty.

Let me know what you think of this "twist". Thank you for reading this relatively long post.

[Horst.Epp]

Not confirmed
Here the .. date is always the modification date of the current dir.
when I go up (Backspace) TC points to the previous dir and its date is exactly the same which was previously displayed under ..
Only exceptions are dirs which are links to other dirs.

[jiangzhenjerry]

@Horst.Epp What you described is the natural way that I would prefer. If what I encounter doesn't happen on your side, then it may be something related to the Windows Insider (and for at least a year LOL).

[Horst.Epp]

@Horst.Epp What you described is the natural way that I would prefer. If what I encounter doesn't happen on your side, then it may be something related to the Windows Insider (and for at least a year LOL).

I guess thats not a function of any Windows Insider builds.
Also we all have the builds from a year ago as production build
and there was never any complain about this.

[petermad]

2jiangzhenjerry
I cannot reproduce what you describe either. Do you see it on all kind of drives/partitions?

[jiangzhenjerry]

@Horst.Epp: Based on your comment, I tried on some (ancient) Windows builds that I still have at hand:
Windows 8.1 Build 9600 (as WindowsToGo): No issue.
Windows 10 Build 14393 (as WindowsPE): No issue.
So it only happens on later Windows builds, and I do see it in every Windows preview build since last year. It could also be related to how I configure my Windows though.

@petermad: Thank you for your time spent as well. I see it in all kinds of drives and partitions (internal/external, SSD/HDD).

[umbra]

I see the same thing as jiangzhenjerry. On the current RTM Windows build (19042), it shows the current folder's modification time. But on the latest insider build (21376) the shown times are inconsistent. Sometimes, they show the current folder's time, sometimes the parent folder's time.

BTW, jiangzhenjerry, the root folder is still a folder and it has a modification time as well. You can try this in the PowerShell:

Code: Select all

get-item \ | fl

Additionally, if the jiangzhenjerry is on the Dev channel, like me, he might be referring to the builds 19536-21376, that started over a year ago and haven't been released as RTM yet.

[jiangzhenjerry]

@umbra: Thank you very much for confirming that I'm not crazy You are right, I'm on the Dev Channel of Windows Insider, and I've been experiencing this for over a year.

I didn't know that the root of a partition has dates as well - thank you for this information. In my example, D:\ and D:\$RECYCLE.BIN\ happen to have the same modification date, hence I was misled. I have added a note in the original post about this.

[ghisler(Author)]

Actually ".." is a directory just like any other subdirectory, and it has its own timestamp in the directory list. Total Commander simply displays the date which Windows reports for "..". Normally the ".." item is created at the same time as the directory it is in, so it should be the date of that directory and not its parent. That's at least the case here on Windows 10 1909 I'm using here.

Maybe someone at Microsoft had the "bright" idea that ".." must refer to the parent, so ".." should have the date of the parent directory. The Windows 10 devlopment has been a really big mess because Microsoft layed off almost all internal testers (source) and left tresting only to insiders - that's why we got so many disaters lately like the printer bug. So they probably made a mistake when trying to change the behaviour of "..", and no one noticed because there is no systematic testing any more.

[umbra]

Actually, I tested it a bit more and there is some consistency on the new Insider builds: For "..", TC always shows the parent folder time with the current folder's attributes. Except in root subfolders - they show their own time instead of the parent (partition root) time. But I can't tell whether this is because of what Windows returns or how TC requests the data.

Based on what I see and what ghisler wrote, there is some Windows API, that used to return incorrect time for ".." and MS decided to fix it in the Insiders Dev builds. But because TC misuses it to get information about the current directory ("."), TC now shows a wrong time.
Or not, because showing the current folder's time and attributes next to "..", which always meant the parent folder, is technically wrong. Though, I understand that it might be practically more useful that way.

Also, we are talking about the Windows Insider Dev builds. Bashing them for potentially containing new bugs is like bashing initial Beta builds of TC for the same thing. I don't think that's fair.

[Horst.Epp]

I fully agree with Umbra.
As long as I don't see anything unexpected in my actual official latest production Windows build
there is no reason at all to complain about such effects.

[ghisler(Author)]

ut because TC misuses it to get information about the current directory (".")

It doesn't misuse it, it just shows the date windows reports for "..". You should see the same date and time as in cmd.exe when using the 'dir' command.

[jiangzhenjerry]

You should see the same date and time as in cmd.exe when using the 'dir' command.

You are right. But based on this information and prior discussions, I feel like Microsoft actually fixed a (historical) bug rather than introduced a new bug. When I do:

Code: Select all

dir "D:\Downloads\Total Commander"

on the stable Windows 10 release or anything prior to that, it shows:

Code: Select all

2021/05/06  10:00    <DIR>          .
2021/05/06  10:00    <DIR>          ..
2021/05/06  10:32    <DIR>          1 Program
(rest omitted)

which I think is wrong, because it doesn't differentiate "." and ".." at all, showing the same result. On the other hand, when I run the command above on the Windows 10 Dev Channel builds, "." and ".." are differentiated correctly:

Code: Select all

2021-05-06  10:00    <DIR>          .
2018-12-14  10:07    <DIR>          ..
2021-05-06  10:32    <DIR>          1 Program
(rest omitted)

Now I understand that TC shows the date of whatever "dir" chooses to show. However, would it be more practical for TC to actually show the date of "."? It is just not very intuitive for me to see the parent directory's date when I'm within a child directory. Besides, the upside is that making such change won't break the compatibility with earlier Windows builds - as "." and ".." are basically treated the same in "dir" in those builds.

[umbra]

It doesn't misuse it, it just shows the date windows reports for "..". You should see the same date and time as in cmd.exe when using the 'dir' command.

That is a good hint. When running the "dir", the new Windows builds no longer show the same timestamp for "." and "..". Instead, each entry shows the correct one now. Also, for folders in the partition root (e.g. "\Program Files\, "\Users\", ..."), the "dir" command no longer lists "..", only ".". So it looks like MS did indeed change their API. I consider that to be a fix, because the old behavior was incorrect. Whether it is a good idea to fix it after so many years, that's a different thing. And I don't remember them announcing it, either. But who knows, whether they will actually release it that way or not.

If you think they should not change the API behavior, maybe you should report that as a potential problem. The Insider builds even have a build-in tool for that.