Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.basic.visual.misc > #1798 > unrolled thread

Getting some system information via VBSCript

Back to article view | Back to comp.lang.basic.visual.misc

Contents

  Getting some system information via VBSCript vincent.belaiche@gmail.com (Vincent Belaïche) - 2013-07-10 12:16 +0200
    Re: Getting some system information via VBSCript "Mayayana" <mayayana@invalid.nospam> - 2013-07-10 08:53 -0400
      Re: Getting some system information via VBSCript vincent.belaiche@gmail.com (Vincent Belaïche) - 2013-07-10 22:46 +0200
        Re: Getting some system information via VBSCript "Mayayana" <mayayana@invalid.nospam> - 2013-07-10 19:06 -0400
          Re: Getting some system information via VBSCript "Theo Tress" <rbk@online.de> - 2013-08-14 15:21 +0200
            Re: Getting some system information via VBSCript "Mayayana" <mayayana@invalid.nospam> - 2013-08-14 10:16 -0400
              Re: Getting some system information via VBSCript Deanna Earley <dee.earley@icode.co.uk> - 2013-08-14 16:41 +0100
                Re: Getting some system information via VBSCript "Mayayana" <mayayana@invalid.nospam> - 2013-08-14 11:53 -0400
            Re: Getting some system information via VBSCript ralph <nt_consulting@yahoo.com> - 2013-08-14 11:23 -0500
    Re: Getting some system information via VBSCript Deanna Earley <dee.earley@icode.co.uk> - 2013-07-11 09:48 +0100
      Re: Getting some system information via VBSCript vincent.belaiche@gmail.com (Vincent Belaïche) - 2013-07-12 22:00 +0200

#1798 — Getting some system information via VBSCript

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.

[toc] | [next] | [standalone]

#1799

  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"" <vincent.belaiche@gmail.com> wrote in message 
news:8061win2ic.fsf@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. 

[toc] | [prev] | [next] | [standalone]

#1800

"Mayayana" <mayayana@invalid.nospam> writes:

>   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.

[toc] | [prev] | [next] | [standalone]

#1801

| 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

[toc] | [prev] | [next] | [standalone]

#1804

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.

[toc] | [prev] | [next] | [standalone]

#1805

| 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. 

[toc] | [prev] | [next] | [standalone]

#1806

On 14/08/2013 15:16, Mayayana wrote:
>    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.

If you're going to say I'm wrong, at least be consistent. Which of what 
you said do you actually mean?
> Nor does it have anything to do with desktop.ini files, as Deanna
> thought.
Or
> 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.

> 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)

> 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.

-- 
Deanna Earley (dee.earley@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the 
group.)

[toc] | [prev] | [next] | [standalone]

#1807

| 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. 

[toc] | [prev] | [next] | [standalone]

#1808

On Wed, 14 Aug 2013 15:21:05 +0200, "Theo Tress" <rbk@online.de>
wrote:

>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 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

[toc] | [prev] | [next] | [standalone]

#1802

On 10/07/2013 11:16, Vincent Belaïche wrote:
> Hello,
>
> I have written the following script
> '#######################################################################
<SNIP>
>     If ((iAttr And 16 ) <> 0) And ((iAttr And 1 ) = 0) Then
<SNIP>
> '######################################################################

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.

> 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,

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

> ...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".

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)

-- 
Deanna Earley (dee.earley@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the 
group.)

[toc] | [prev] | [next] | [standalone]

#1803

Deanna Earley <dee.earley@icode.co.uk> writes:

> On 10/07/2013 11:16, Vincent Belaïche wrote:
>> Hello,
>>
>> I have written the following script
>> '#######################################################################
> <SNIP>
>>     If ((iAttr And 16 ) <> 0) And ((iAttr And 1 ) = 0) Then
> <SNIP>
>> '######################################################################
>
> 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.
>
>> 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,
>
> Yes, because it is a "system" folder (see it has a desktop.ini file)
>
>> ...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".
>
> 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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.basic.visual.misc

csiph-web