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

Tech-Archive recommends: Fix windows errors by optimizing your registry

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

Date: Fri, 5 Mar 2004 17:16:16 -0800

Explorer ignores RO on a file for the sake of usability. (Oh - the irony!)
In the modern world, we can use a modern file system (NTFS) that supports
security descriptors instead of a single bit per file that determines
"everyone can write" vs "nobody can write".

I've complained about the folder RO UI. So have lots of other people. It's
a common enough complaint that the shell guys will probably find a better
way to present the control in the future (Longhorn?). We're stuck with it
on current releases, though. 

-- 
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:%23d%23mgFwAEHA.580@TK2MSFTNGP11.phx.gbl...
> RO on a directory is a player in desktop.ini processing? I didn't know
that.
> :-/
>
> Actually RO on a *file* is still honored rather widely. Command line stuff
> in particular will honor it. And there's usefulness in the other bits,
> especially at the file level. It's just the directory entries that get
> strange.
>
> My only complaint with attribute bits is the way RO on a directory is
> handled by the GUI at present. Tri-stating with a binary option gets
really
> weird and, as you've seen, extremely difficult to explain.
>
> -- 
> 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
>
>
> "Drew Cooper [MSFT]" <dcoop@online.microsoft.com> wrote in message
> news:%23bQ$WovAEHA.3836@TK2MSFTNGP10.phx.gbl...
> > 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
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >>.
> >> >>
> >>
> >
> >
>
Quantcast