Getting some system information via VBSCript

[Vincent Belaïche]

Hello,

I have written the following script
'#######################################################################
Dim oFSO
Set oFSO = WScript.CreateObject("Scripting.FileSystemObject" )

Const iIS_DIRECTORY = 16
Const iIS_READ_ONLY = 1

Function HasWriteAccess(sFolderName_IN) 'As String
Dim oFolder
Set oFolder = oFSO.GetFolder(sFolderName_IN)
Dim iAttr
iAttr = 0
On Error Resume Next
iAttr = oFolder.Attributes
Set oFolder = Nothing
If ((iAttr And 16 ) <> 0) And ((iAttr And 1 ) = 0) Then
HasWriteAccess = "true"
Else
HasWriteAccess = "false"
End If
End Function

Dim oWshShell, sPrograms, sWritablePrograms
Set oWshShell = WScript.CreateObject("WScript.Shell" )
sPrograms = oWshShell.SpecialFolders("Programs")
sWritablePrograms = HasWriteAccess(sPrograms)

WScript.Echo "Programs=" & sPrograms
WScript.Echo "WritablePrograms=" & sWritablePrograms
'######################################################################

and when I run it the response is as follows:
'######################################################################
Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation 1996-2001. Tous droits réservés.

Programs=C:\Documents and Settings\Vincent\Menu Démarrer\Programmes
WritablePrograms=false
'######################################################################

Now, this answer seems wrong to me, because if I open some command line
console and I do:

Rem ###################################################################
cd /D "C:\Documents and Settings\Vincent\Menu Démarrer\Programmes"
mkdir toto
Rem ###################################################################

That will work without error, i.e. --- contrary to the script response I
do have write access on special folder "Programs".

Any help is welcome.

Vincent.

[Mayayana]

First, you're in the wrong group. This is VB.
VBScript is microsoft.public.scripting.vbscript

If you want to check your "permissions" in
a folder it might be easiest to just try writing
a file and check for an access deined error. (I
don't remember the number offhand.) Folders
have read-only attribute. (As far as I know,
Microsoft has never offered a coherent reason
for that, but I think it's true from XP on.)
--
--
"Vincent "Bela�che"" <***@gmail.com> wrote in message news:***@gmail.com...
| Hello,
|
| I have written the following script
| '#######################################################################
| Dim oFSO
| Set oFSO = WScript.CreateObject("Scripting.FileSystemObject" )
|
| Const iIS_DIRECTORY = 16
| Const iIS_READ_ONLY = 1
|
| Function HasWriteAccess(sFolderName_IN) 'As String
| Dim oFolder
| Set oFolder = oFSO.GetFolder(sFolderName_IN)
| Dim iAttr
| iAttr = 0
| On Error Resume Next
| iAttr = oFolder.Attributes
| Set oFolder = Nothing
| If ((iAttr And 16 ) <> 0) And ((iAttr And 1 ) = 0) Then
| HasWriteAccess = "true"
| Else
| HasWriteAccess = "false"
| End If
| End Function
|
| Dim oWshShell, sPrograms, sWritablePrograms
| Set oWshShell = WScript.CreateObject("WScript.Shell" )
| sPrograms = oWshShell.SpecialFolders("Programs")
| sWritablePrograms = HasWriteAccess(sPrograms)
|
| WScript.Echo "Programs=" & sPrograms
| WScript.Echo "WritablePrograms=" & sWritablePrograms
| '######################################################################
|
| and when I run it the response is as follows:
| '######################################################################
| Microsoft (R) Windows Script Host Version 5.7
| Copyright (C) Microsoft Corporation 1996-2001. Tous droits réservés.
|
| Programs=C:\Documents and Settings\Vincent\Menu Démarrer\Programmes
| WritablePrograms=false
| '######################################################################
|
| Now, this answer seems wrong to me, because if I open some command line
| console and I do:
|
| Rem ###################################################################
| cd /D "C:\Documents and Settings\Vincent\Menu Démarrer\Programmes"
| mkdir toto
| Rem ###################################################################
|
| That will work without error, i.e. --- contrary to the script response I
| do have write access on special folder "Programs".
|
| Any help is welcome.
|
| Vincent.

[Vincent Belaïche]

Post by Mayayana
First, you're in the wrong group. This is VB.
VBScript is microsoft.public.scripting.vbscript
If you want to check your "permissions" in
a folder it might be easiest to just try writing
a file and check for an access deined error. (I
don't remember the number offhand.) Folders
have read-only attribute. (As far as I know,
Microsoft has never offered a coherent reason
for that, but I think it's true from XP on.)

Thank you for your feedback.

Concerning the "read-only attribute", that is not completely true: I
have found some folders with read/write attribute and some others with
read-only. But I cannot understand the reason/meaning for the attribute.

I will try to forward this discussion to
microsoft.public.scripting.vbscript when I can subscribe to this group.

Vincent.

[Mayayana]

| Concerning the "read-only attribute", that is not completely true: I
| have found some folders with read/write attribute and some others with
| read-only.

Maybe there are some not marked read-only. So what?
Either way, file attributes are not the same as permissions.
If the folder is read-only you can still write to it. If you
nmanage to clear that attribute via script nothing will change
and it won't affect permissions.
*The read-only attribute is not a way to test write access.*

| But I cannot understand the reason/meaning for the attribute.

It's nonsense. Ignore it. If you want the full
explanation see here:

http://support.microsoft.com/kb/326549

[Theo Tress]

Well, I tried checking the r/o attribute in Vista:

- One of my TMP-Subdirs was already marked as r/o. I could create a new txt
file in it and write to it. The file was r/w, the subdir still r/o.

- I changed the subdir attribute to r/w and back to r/o, confirmed
changement for all files, and the txt file was now r/o also.

This was reproduceable and just that what I've expected: Changing the subdir
attribute invokes a dialogue and this could change the underlying files and
subdirs.

[Mayayana]

| Well, I tried checking the r/o attribute in Vista:
|
| - One of my TMP-Subdirs was already marked as r/o. I could create a new
txt
| file in it and write to it. The file was r/w, the subdir still r/o.
|
| - I changed the subdir attribute to r/w and back to r/o, confirmed
| changement for all files, and the txt file was now r/o also.
|
| This was reproduceable and just that what I've expected: Changing the
subdir
| attribute invokes a dialogue and this could change the underlying files
and
| subdirs.
|

What you're describing has nothing to do with
permissions. Nor does it have anything to do with
the quirky fake r/o default setting on folders.

Folders can be marked read-only. It doesn't mean
anything. It's nonsense. For whatever reason, it's the
default setting. Nor does it have anything to do with
desktop.ini files, as Deanna thought. (At least not on
XP. I assume it's the same on Vista/7.) One can add
a desktop.ini to a folder marked r/o or system in order
to customize the folder by doing things like using a
special icon. I do that by writing a desktop.ini like so
on XP:

[.ShellClassInfo]
IconFile=C:\WINDOWS\NewIconStorage\uni1.ico
IconIndex=0

The desktop.ini won't work unless the folder has either
the system or r/o attribute. That particular behavior
is also arbitrary nonsense that MS has never explained,
as far as I know. But all of my folders are marked r/o.
Most do not have a desktop.ini file. R/o, by itself, means
nothing with folders.

What you're talking about is something altogether
different. When you changed settings by hand
in the Properties window the dialogue asked if you
want to apply those settings to all subfolders and
files. That's an extra step. All that it demonstrates
is that it's possible to get Windows to mark an
entire folder of files as r/o, or to clear to r/o marker,
by fiddling with the Properties window.

In other words, even when you specifically set a
folder r/o it has no affect on anything. It *just
so happens* that when you do it through the
Properties window you're presented the option to
also change settings on subfolders and files.

So the morals of the story: 1) Ignore r/o on folders.
It's nonsense. (Unless you want to play with
desktop.ini files.) 2) Permissions shouldn't be confused
with file attributes.

[Deanna Earley]

Post by Mayayana
Folders can be marked read-only. It doesn't mean
anything. It's nonsense. For whatever reason, it's the
default setting. Nor does it have anything to do with
desktop.ini files, as Deanna thought. (At least not on
XP. I assume it's the same on Vista/7.) One can add
a desktop.ini to a folder marked r/o or system in order
to customize the folder by doing things like using a
special icon. I do that by writing a desktop.ini like so
[.ShellClassInfo]
IconFile=C:\WINDOWS\NewIconStorage\uni1.ico
IconIndex=0
The desktop.ini won't work unless the folder has either
the system or r/o attribute.

If you're going to say I'm wrong, at least be consistent. Which of what
you said do you actually mean?

Post by Mayayana
Nor does it have anything to do with desktop.ini files, as Deanna
thought.

Or

Post by Mayayana
The desktop.ini won't work unless the folder has either the system or
r/o attribute.

Those two statements are completely contradictory, the first saying my
explanation was garbage, the second then restates what I said.

The readonly flag does not mean there must be a desktop.ini file, nor
does having a desktop.ini file mean it must be readonly.
Explorer will only look for and read desktop.ini if the folder is set
readonly.

Post by Mayayana
That particular behavior is also arbitrary nonsense that MS has never
explained, as far as I know.

http://msdn.microsoft.com/en-us/library/windows/desktop/cc144102(v=vs.85).aspx
(I know that article says attrib +s but the function actually sets +r)

Post by Mayayana
But all of my folders are marked r/o. Most do not have a desktop.ini
file. R/o, by itself, means nothing with folders.

Only that Explorer should look at Desktop.ini.

[Mayayana]

| The readonly flag does not mean there must be a desktop.ini file, nor
| does having a desktop.ini file mean it must be readonly.
| Explorer will only look for and read desktop.ini if the folder is set
| readonly.

OK. No disagreement. I was just trying to clear
up a potentially misleading statement you'd
made before:

-----------------
The read only attribute has no effect on whether you can write to the
folder or not.
It makes the folder as a "system" folder that has a desktop.ini file.
----------------

I read that to say that a folder with a r/o
attribute is a system folder and has a
desktop.ini file. I was trying to make clear
that r/o for folders has no real significance.

[ralph]

Post by Theo Tress
- One of my TMP-Subdirs was already marked as r/o. I could create a new txt
file in it and write to it. The file was r/w, the subdir still r/o.
- I changed the subdir attribute to r/w and back to r/o, confirmed
changement for all files, and the txt file was now r/o also.
This was reproduceable and just that what I've expected: Changing the subdir
attribute invokes a dialogue and this could change the underlying files and
subdirs.

Mayayana covered the issue, although perhaps calling it "nonsense" is
a tad misleading. It is just the way Windows works and has for quite a
while now.

It is important to note Explorer is limited in its ability to fully
manage this setting. And there is a relationship between Read-Only and
the System setting.

Normally, as Mayayana advised, if one just ignores the setting all
goes well. However, if one piddles with folder properties, or with a
rogue install/update, it is possible to create situations that are
counter-intuitive and even troublesome (eg. an app's inability to read
a folder's files). Thus you will find little Microsoft documentation
on Why it is the way it is, but much on what to do when it goes wrong.
<g>

Take a look at the following article.
http://support.microsoft.com/kb/326549

Although not strictly germane to your question, it contains a lot of
useful information.

-ralph

[Deanna Earley]

Post by Vincent Belaïche
Hello,
I have written the following script
'#######################################################################

<SNIP>

Post by Vincent Belaïche
If ((iAttr And 16 ) <> 0) And ((iAttr And 1 ) = 0) Then

<SNIP>

Post by Vincent Belaïche
'######################################################################

The read only attribute has no effect on whether you can write to the
folder or not.
It makes the folder as a "system" folder that has a desktop.ini file.

Post by Vincent Belaïche
'######################################################################
Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation 1996-2001. Tous droits réservés.
Programs=C:\Documents and Settings\Vincent\Menu Démarrer\Programmes
WritablePrograms=false
Now, this answer seems wrong to me,

Yes, because it is a "system" folder (see it has a desktop.ini file)

Post by Vincent Belaïche
...because if I open some command line
Rem ###################################################################
cd /D "C:\Documents and Settings\Vincent\Menu Démarrer\Programmes"
mkdir toto
Rem ###################################################################
That will work without error, i.e. --- contrary to the script response I
do have write access on special folder "Programs".

It's part of your profile, you can write to it.

Permissions may give you a slightly more correct answer to whether you
can write there, but the only reliable way to tell is to try and write
there.

Depending on your apps build process/manifest, Windows may even let you
write to a protected location and really move them elsewhere (lookup
file system virtualisation)

[Vincent Belaïche]

Post by Deanna Earley

Post by Vincent Belaïche
Hello,
I have written the following script
'#######################################################################

<SNIP>

Post by Vincent Belaïche
If ((iAttr And 16 ) <> 0) And ((iAttr And 1 ) = 0) Then

<SNIP>

Post by Vincent Belaïche
'######################################################################

The read only attribute has no effect on whether you can write to the folder or not.
It makes the folder as a "system" folder that has a desktop.ini file.

Post by Vincent Belaïche
'######################################################################
Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation 1996-2001. Tous droits réservés.
Programs=C:\Documents and Settings\Vincent\Menu Démarrer\Programmes
WritablePrograms=false
Now, this answer seems wrong to me,

Yes, because it is a "system" folder (see it has a desktop.ini file)

Post by Vincent Belaïche
...because if I open some command line
Rem ###################################################################
cd /D "C:\Documents and Settings\Vincent\Menu Démarrer\Programmes"
mkdir toto
Rem ###################################################################
That will work without error, i.e. --- contrary to the script response I
do have write access on special folder "Programs".

It's part of your profile, you can write to it.
Permissions may give you a slightly more correct answer to whether you can write there, but the only reliable
way to tell is to try and write there.
Depending on your apps build process/manifest, Windows may even let you write to a protected location and
really move them elsewhere (lookup file system virtualisation)

Thank to both of you about the clear answers. I will try that.

VBR,
Vincent.