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

From: Drew Cooper [MSFT] (dcoop_at_online.microsoft.com)
Date: 03/05/04

  • Next message: Walter Clayton: "Re: Read Only flag is set on all folders on all drives." 
    Date: Fri, 5 Mar 2004 13:37:41 -0800

    Actually, complain to the vendor about changing that attribute because it
    can also mess up Explorer. The shell uses that attribute to signal that it
    could be a "special" folder and looks for a desktop.ini file with more info.
    That may have been a questionable design decision, too. Not only is it also
    non-intuitive, but it's one more reason not to get rid of file attributes
    altogether. :-( 

    -- 
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.
"Walter Clayton" <w-claytonNO@SPmvpsAM.org> wrote in message
news:uA29W5mAEHA.808@TK2MSFTNGP12.phx.gbl...
> 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
> >>>
> >>>
> >>
> >>
> >>.
> >>
>
  • Next message: Walter Clayton: "Re: Read Only flag is set on all folders on all drives."
    Loading