Re: Read Only flag is set on all folders on all drives.

From: Walter Clayton (w-claytonNO_at_SPmvpsAM.org)
Date: 03/05/04 

Date: Thu, 4 Mar 2004 23:57:25 -0500

OK. Proof of what's happening time. Keep in mind that what Drew stated is
the absolute truth. Literally. What you see in the GUI with regard the RO
attribute on a directory has nothing to do with the current state of the
bit. Literally. To put it another way, it's a questionable design decision
of the part of MS since it is inconsistently applied. That however is
irrelevant to the issue at hand.

There are only a few apps that are actually impacted by the RO attribute on
an actual directory. First thing is to give the vendor an ear full since RO
at the directory level is ignored by over 99% of the vendors on the market
in a local setting and is generally only a player, if at all, on 'net
shares. In reality RO on an directory is irrelevant and at best a residual
attempt from FAT days of employing a modicum of data protection. And the
latter was typically ignored.

That stated, if you really think that RO on the directory is the issue then
do the following:

First validate that RO is set:

start->run->cmd [enter]

{drive}: [enter] - note this only required if the "problem" directory is on
a drive other than C: or command prompt is set to open at a default location
that has a different drive letter other than the "problem" directory. If
command prompt initially starts on the same drive as the "problem"
directory, this should be skipped.

cd {parent of the "problem" directory} - i.e. if the "problem" directory is
"c:\something\problem" then at this point enter "cd:\something". The key
here is that you must located at the root of the "problem" directory. This
is important. If you do not point command prompt to the correct directory
then post back and I'll think of something. Next type the following in
command prompt:

attrib "problem directory" [enter]

Notice carefully anything that appears to the left of full path name. If you
do not see the letter R then RO is *not* set on the directory. To illustrate
this to yourself enter the following:

c: [enter}
cd \ [enter}
attrib *.*[enter}

Carefully note the display next to c:\boot.ini. Do you see the letter "R".
This letter means that read only has been set on the file ":\boot.ini".

Now back to your "problem" directory. Did you see "R" to the left of the
path name? If not, then you need to look at security settings on the
directory. Since that gets rather involved I'll leave that until you're
ready.

*If* you see "R" to the left of the path, then simply enter the following:

attrib -r {"problem directory"} [enter]

This will actually clear the RO attribute on a directory. Now retry your
app. If it still fails, and unless it's Quickbook or a 'net based access
(Quickbook is the *only* app that still checks RO on a directory AFAICR)
then you're going to have to address security. Again, since this isn't a
simple process I'll defer until you've validated that RO is not in fact your
issue. 

-- 
Walter Clayton - MS MVP(WinXP)
Associate Expert
http://www.microsoft.com/windowsxp/expertzone
Any technology distinguishable from magic is insufficiently advanced.
http://www.dts-l.org
"Geoff" <anonymous@discussions.microsoft.com> wrote in message 
news:738d01c40267$1af7a1e0$a501280a@phx.gbl...
> I'm experiencing the same problems.  I've re-applied the
> permissions to Everyone - Full Control and still seem to
> have the problem.  Any other ideas?  Another program is
> unable to write to the directory and it's crucial to this
> app.
>>-----Original Message-----
>>The checkbox is a tri-state.  Gray + check means that no
> attribute change is
>>being applied to its contained files.
>>
>>It's unlikely that the read only attribute is the
> problem.  Check the file
>>permissions.
>>-- 
>>Drew Cooper [MSFT]
>>This posting is provided "AS IS" with no warranties, and
> confers no rights.
>>
>>
>>"Gary" <gary@ftgcorp.com> wrote in message
>>news:OxW9DxB$DHA.2516@TK2MSFTNGP11.phx.gbl...
>>> I'm running 2003 server and discovered the problem
> when Visual Studio.Net
>>> was unable to add a new file to a project located on
> the server.  Files
>>can
>>> be edited and saved but not created.  The error states
> that the folder
>>does
>>> not have write permission.  On looking at the server
> file system I found
>>> that all folders on all drives have the read only flag
> set but grayed.  I
>>> can uncheck the flag click apply and OK but when I go
> back to the property
>>> *** the grey check mark is back.
>>> As recommended in
>>> http://support.microsoft.com/default.aspx?scid=kb;en-
> us;Q326549 I have
>>tried
>>> the attrib command but the results are the same.
>>>
>>> The problem is consistent from the drive root folders
> throughout the
>>trees.
>>> I'd appreciate any advice as this is killing a
> critical project.
>>> Thanks.
>>>
>>> Gary
>>> gary@ftgcorp.com
>>>
>>>
>>
>>
>>.
>>