Are all folders in Wndows/system32 read only?

[cursillo]

In an attempt to rid my computer of some byproducts from a virus attack, I had to make the windows/system32 directory NOT READ-ONLY. I initially selected "just this folder" from the prompt that preceeds the change. I managed to find the oddball file and remove it, and when I went to re-establish the directory as READ-ONLY, I inadvertantly selected READ-ONLY "for this folder and all subfolders" (or words to that affect).
.
My question: Any harm in this setting (system32 and all subfolders as READ-ONLY) OR are there only selected folders that should be READ ONLY.

Any help would be appreciated.

 

[bcastner]

Is this XP?

If so the "read-only" attribute is only a flag under this OS (and future) to identify folders in which a desktop.ini files needs to be read by Explorer.

It has lost all of its traditional meaning. Perhaps this MS KB article can explain the issue:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;326549

Best,
Bill Castner

 

[cursillo]

Thank you for such a quick reply. I read the link on Read Only and must admit after three reads I'm a bit confused. I'm sure it makes more sense to a seasoned pro. From what i could gleam, it seems from the article and your reply that the folder property (or attribute) that I was able to change (XP Home Edition) likely does not have far reaching consequences. I suppose any peculiarty, if any, would surface in Windows Explorer.
I would elaborate a bit more if I were at the computer in question. At work here I'm on 98SE and I as you know things are a bit different. Thanks again.

 

[bcastner]

Essentially the "read-only" attribute of a folder fell by the wayside as the security model changed between NT versions (including XP) and Win9x versions.

Under Win9x, for example, the security model was essentially a Share permissions: folder/share password model. NT, including XP, uses a very different security model based on users.

This is part and parcel of the richness offered by the NTFS filestore as well. I know the change in model drives Win9x folks crazy, but you really have to change your way of thinking when you start using NT based OS versions.

The primary security focus under NT is the username and password. The primary security focus under Win9x was the share itself.

Old Win9x guys keep trying to bend NT-based OS clients such as XP to "fit" the older security model. It just is not possible. This in the main explains the thinking behind XP Home, and the default of XP Pro to have "Simple file sharing - recommended' enabled. As long as the Guest account was enabled under XP Pro and not disabled under Home, the shares should work between Win9x and NT-based XP.

This was the intention of the "Network Setup Wizard" of XP as well, to keep someone from messing with the settings so that simple file and print sharing between legacy clients and XP was as simple as possible.

I agree it does not work as well as it must. But part of the problem is that the experienced Win9x people just do not "get" the Security Model change introduced with NT.

In answering questions I often over specify; I will have people open Guest when in a technical way it is not necessary; or recommend the synchronization of passwords in all workstations.

In answering a newsgroup or a forum post here, my interest is to create a sufficient common ground that both the older share security model and the present user security model can make the small LAN work.

And fundamental to this all is the richness offered by the NTFS filestore. It will only get more involved, not less, as Microsoft intends to add non-standard meta elements to NTFS in its future filestore plans.

A fairly long answer to your question, so let me end with a brief answer: Under XP, a read-only attribute on a folder is only a flag for Explorer to look to see if there is a desktop.ini file. It means nothing else, even though it did mean something else under Win9x.

Best,
Bill Castner

 

[linney]

If you clear the flag from a read only folder and then reset it again as read only and press Apply, and pass the attribute down to sub folders and files, the files therein become read only in the strict sense and you will not be able to write to them until the attribute is changed from read only.

Files that are added to a folder after the read only attribute is set on that folder and passed down do not become read only and are freely written to.

 

[bcastner]

linney,

You cannot clear the flag from a system designated read-only folder under XP.

I agree with the inheritance for files, that is conforms to the traditional sense of read only under Win9x.

If you are suggesting you can toggle under a folder read-only status for children files on and off by flipping the switch on the parent folder for the read-only attribute, I suspect we disagree.

 

[linney]

In the example stated (System32), it may have an effect on .log, .dat, .evt or similar "written to" files by the user. It may not be applied to the hidden Sam or Security type logs in Config (I can't open them, easily, to check). Not wishing to experiment with "cursillo"s" example too far, I did notice odd behavior in the .evt files when their attributes were set to read, things like combined event file logging, to no logging were shown in the Event Viewer.


Whether we are agreeing or disagreeing I am not sure.

You can easily demonstrate what I am referring to by placing any old .txt or .log file in a folder, then change the read attribute of that folder (allowing it to be passed down to files) and then try and write (and save) the text.
Remove the read attribute of the folder and pass it down to once again write to the files.

 

[bcastner]

Ignore true "System" Folders, as that complicates things.

. I misrepresented the case, and you rightly corrected me here, that flipping the "Read only" status of a regular folder will prompt you for what to do with the child files underneath. As long as nothing is unusual about the files, (for example, log files for an active process, or those with a System attribute), for perfectly "normal" files the Read-only will be reset.

. For Folders as an object, the "Read-only" attribute is essentially both meaningless (as I noted above) and essentially out of your control.

You can uncheck that box forever, but it is not going to change its status when you go back and look again.

. If there exists at the folder root a desktop.ini, that switch box will report nothing;
. If there does not exist at folder root a desktop.ini, it is Read-Only.

The interesting thing is that this is not NTFS, but an XP decision as to how to report things under Explorer.

There is a lot of unexplored bits available under the NTFS filestore, some very clever ways to do mount points, junctions, and streams. And you will see more unconventional uses by Microsoft of the NTFS filestore in the reasonable future.

Ignoring that: The answer is no, you cannot change the Read-only attribute of folders and have it persistant. And ignore it, as it really does not mean Read-only except on CDs.