strange (?) file coloring in "show hidden files" mode

[petermad]

I have tested in the debugger what is going on:
1. The ".." entries really have set these hidden or system attributes shown when cm_switchHidSys is on
2. When cm_switchHidSys is off, TC filters out all files and folders which have these attributes set, including ".."
3. When ".." is filtered out, TC adds its own ".." entry with the attributes and date taken from the folder itself

My suggested changes would be:
1. Do not filter out ".." when cm_switchHidSys is off to get the date/time of the ".." entry
2. Reset the attribite field of ".." either to just "directory", or "directory"+"read only" but ignore hidden and system.
This could be done either when cm_switchHidSys is off, or also when it's on.

How about just:
TC shows the ".." entry with the attributes and date taken from the folder itself, whether or not cm_switchHidSys is on or off

[white]

Your post wasn't a description, it was a question - note question marks!
So i answered you.

I see, I misunderstood.

That is not what I see, here the attributes are always the same on [..] as it is on the folder if I go updir - on NFTS and exFAT drives.

And you are sure the folder and parent of that folder have different attributes?

On FAT drives. the attrubutes for [..] are always blank.

Confirmed. On a FAT drive, "." and ".." are created in the FAT table when a folder is created and have the same timestamp and no rahs attributes. These FAT entries do not change when you change attributes of the folder, right?

1. Open a Command Prompt Window
2. Go to a FAT drive
3. Execute commands:

   Code: Select all

   md \parent
   md \parent\folder
   dir \parent\folder\.*
   

4. Use TC to change timestamp and attributes of "parent" and "parent\folder"
5. Execute command:

   Code: Select all

   dir \parent\folder\.*
   

   The output is the same, isn't it?

On NTFS drives, "." and ".." are not stored as separate entries right? The attributes for these entries are derived from the attributes of the folder and parent folder. Repeat the steps above, but in step 2 go to a NTFS drive. Now step 5 does not give the same results.

[petermad]

2white

And you are sure the folder and parent of that folder have different attributes?

Well, the the folder is the root - I don't think I can set the h and s attribute for the root.

Open a Command Prompt Window
Go to a FAT drive
Execute commands:

Code: Select all

md \parent
md \parent\folder
dir \parent\folder\.*

Use TC to change timestamp and attributes of "parent" and "parent\folder"
Execute command:

Code: Select all

dir \parent\folder\.*

The output is the same, isn't it?


On NTFS drives, "." and ".." are not stored as separate entries right? The attributes for these entries are derived from the attributes of the folder and parent folder. Repeat the steps above, but in step 2 go to a NTFS drive. Now step 5 does not give the same results.

Confirmed.


But all I want to know, is if it possible to manually create folders like in KozakMak's screenshots - that is: can I create a folder in the root of a NTFS drive and somehow make the h and s attributes not be shown for the folder, but be shown for the [..] entry when I go into that folder?

[white]

And you are sure the folder and parent of that folder have different attributes?

Well, the the folder is the root - I don't think I can set the h and s attribute for the root.

Did you read the following post that I posted in this thread:

1. The ".." entries really have set these hidden or system attributes shown when cm_switchHidSys is on

Indeed, when executing the dir command in a Command Prompt window, the ".." is not shown unless you instruct dir to also show hidden files.
The attributes seem to be the same as what GetFileAttributes returns for the root folder of NTFS drives. See here.

But all I want to know, is if it possible to manually create folders like in KozakMak's screenshots - that is: can I create a folder in the root of a NTFS drive and somehow make the h and s attributes not be shown for the folder, but be shown for the [..] entry when I go into that folder?

The [..] entry points to the parent folder (so the root folder in this case), not the folder itself. As mentioned above the root on NTFS drives always has the hs attributes.

[petermad]

The [..] entry points to the parent folder (so the root folder in this case), not the folder itself. As mentioned above the root on NTFS drives always has the hs attributes.

I think we are not talking about the same. but try this:
In TC on and NTFS drive make a new dir "newtest" in the root. The attributes shown for newtest is shown as ---- . Now go into the newtest folder. The attributes shown for [..] is ---- which is the attribute of the newtest folder not of the root - does it show the attributes --hs on your system?

[Lsched]

The [..] entry points to the parent folder (so the root folder in this case), not the folder itself.

That's not so. On my system, all [..] entries have the same attributes as the folders themselves. Attributes differ only when the folder is redirected.
Please note that in Kozakmak's screenshots not only the attributes differ, but the date/time of the "Program Files" folder.

[white]

In TC on and NTFS drive make a new dir "newtest" in the root. The attributes shown for newtest is shown as ---- . Now go into the newtest folder. The attributes shown for [..] is ---- which is the attribute of the newtest folder not of the root - does it show the attributes --hs on your system?

Yes, if cm_switchHidSys is on. No, if cm_switchHidSys is turned off. As explained by Mr. Ghisler, when cm_switchHidSys is turned off TC adds its own ".." entry with the attributes and date taken from the folder itself (instead of from the parent).

I have tested in the debugger what is going on:
1. The ".." entries really have set these hidden or system attributes shown when cm_switchHidSys is on
2. When cm_switchHidSys is off, TC filters out all files and folders which have these attributes set, including ".."
3. When ".." is filtered out, TC adds its own ".." entry with the attributes and date taken from the folder itself

[petermad]

Yes, if cm_switchHidSys is on. No, if cm_switchHidSys is turned off. As explained by Mr. Ghisler, when cm_switchHidSys is turned off TC adds its own ".." entry with the attributes and date taken from the folder itself (instead of from the parent).

Yes, but to me, as the user, I see attributes ---- for the [..] entry of the newtest folder no matter whether cm_switchHidSys is on or off - that's what matters.

If I right-click on [..] and open the properties dialog it is also the properties for the folder itself, not the parent folder that is shown. So I expect TC to show the same properties in the file panel as in the properties dialog.

And then there is the issue with the attributes shown in the file panel for [..] entries on FAT partitions. here TC always shows ---- but the properties dialog show the attributes for hidden (and also for archive on Windows 7).

Concerning the date - her TC shows the writedate of the folder itself for the [..] entry on NTFS drives, while it shows the creationdate on FAT drives - the properties dialog shows the creationdate in both cases. If a folder is copied to a FAT drive, TC shows the date of the copying for the [..] entry (as does the dir command), while the properties dialog shows the creationdate of the original folder - so not even Windows is consistent on FAT drives.

[white]

Yes, if cm_switchHidSys is on. No, if cm_switchHidSys is turned off. As explained by Mr. Ghisler, when cm_switchHidSys is turned off TC adds its own ".." entry with the attributes and date taken from the folder itself (instead of from the parent).

Yes, but to me, as the user, I see attributes ---- for the [..] entry of the newtest folder no matter whether cm_switchHidSys is on or off - that's what matters.

Perhaps it's due to differences between Windows versions. I am using Windows 11 Pro 23H2.

In any case, Mr. Ghisler mentioned that he uses real data when the 'cm_switchHidSys' is turned on (meaning that data for ".." is requested from the operating system), and fake data when it is turned off. I think it is clear that this is not ideal. An argument can be made for always using real data, and an argument can be made for always displaying fake data (showing the details for the folder itself instead). It might be best to implement both approaches and provide the user with the choice to decide which one to use.

[petermad]

Perhaps it's due to differences between Windows versions. I am using Windows 11 Pro 23H2.

And I tested on Windows 7 and 10 22H2

It might be best to implement both approaches and provide the user with the choice to decide which one to use.

I think so, and make the fake data approach work the same way on NTFS and FAT

[white]

Perhaps it's due to differences between Windows versions. I am using Windows 11 Pro 23H2.

And I tested on Windows 7 and 10 22H2

I tried on a Windows 10 virtual machine and can confirm your findings. So it seems to be changed in newer Windows versions. Perhaps Microsoft decided that, on NTFS drives, showing the witedate and attributes of the current folder for both "." and ".." doesn't make sense.

It might be best to implement both approaches and provide the user with the choice to decide which one to use.

I think so, and make the faks data approach work the same way on NTFS and FAT

Agreed, that was what I was thinking. Either always show the data the operating system returns for "..", or always show the data of the current folder (fake data).