In the midst of a Kafkaesque episode of IT torture, I realized that all of my Windows 2003 server folders on every drive had a grayed-out (greyed-out) checkbox in the read-only attribute. The value of the checkbox could not be changed. (That is, it appears that it can be cleared, but on review it's set again. This is true even if one requests that changes propagate down the tree.)
In theory this means that somewhere in the tree of child folders there exists a read-only folder.
Was this related to the mind-crumbling miseries of my past week of IT hell?
Probably not, but the truth is dark enough. Microsoft has a kb article on this. I've cleaned it up, the original is poorly written. Emphases mine ...
... Unlike the Read-only attribute for a file, the Read-only attribute for a folder is typically ignored by Windows ... you can delete, rename, and change a folder with the Read-only attribute by using Windows Explorer.
The Read-only and System attributes are only used by Windows Explorer to determine whether the folder is a special folder, such as a system folder that has its view customized by Windows (for example, My Documents, Favorites, Fonts, Downloaded Program Files), or a folder that you customized by using the Customize tab of the folder's Properties dialog box.
As a result, Windows Explorer does not allow you to view or change the Read-only or System attributes of folders.
When a folder has the Read-Only attribute set it causes Explorer to request the Desktop.ini of that folder to see if any special folder settings need to be set.
... if a network share that has a large amount of folders set to Read-only, it can cause Explorer to take longer than expected to render the contents of that share while it waits on the retrieval of the Desktop.ini files. The slower the network connectivity to the share the longer this process can take to the point where Explorer may timeout waiting for the data and render nothing or appear to hang.
Let's walk backwards to appreciate the horror of what Microsoft did here.
Suppose you want to display NTFS metadata like a file's name or comments in an Explorer view. This is a handy way to do what, millennia ago, we did using things like PC Magazine's dirnotes.com utility. Well, it's easy to enter that data, but how does Windows know to display it.
Ahh, here's where the horror of the hack sets in.
The metadata directions are stored in Desktop.ini files for each folder. It would be slow, however, for Windows to check that file every time an Explorer view is to be shown. So Windows 2003 needs to know when to check.
Cue dramatic music.
Some poor benighted soul realized that Windows (95? 98? NT? 2000?) doesn't use the read-only attribute for much. So he (must have been) had a brilliant idea. He'd hijack that attribute, and use it as a way to tell Windows that it needed to check the Desktop.ini file.
We know how the play unfolds now. Once this data value had been used this way the meaning changed. The text says "read-only" but the meaning is "look at the desktop.ini file".
We call that semantic drift.
Of course there's no reason for an attribute that really means "look at desktop.ini" to change the UI for a parent folder attribute of the same name, but that was inherited from the original use of the folder "read-only" attribute. It's a hack side-effect.
Finally, since "read-only" now meant "look at desktop.ini" it had to be reserved for system use, so Windows Explorer can no longer change that attribute. Of course attrib. exe can still change it, but probably you don't want to -- you're really telling Windows then to "ignore desktop.ini".
The Horror, The Horror.
O M G
ReplyDeleteI have been battling this on a folder with 2300 subfolders and it was just killing me since I have to go in to this folder all of the time.
Thank you!