Create Folders and Write To Hard Disk Other than C:
in [Visual Basic]
|
From: Paul Clement on 8 Mar 2010 09:14 On Sun, 7 Mar 2010 23:22:04 -0500, "mayayana" <mayayana(a)nospam.invalid> wrote: � > � � Those are both VBScript hacks with dependencies. Nope. ADSI is a COM library that is already installed. It can be used from VBScript but otherwise has nothing to do with it. Paul ~~~~ Microsoft MVP (Visual Basic)
From: mayayana on 8 Mar 2010 10:24 > � > � Those are both VBScript hacks with dependencies. > > > Nope. ADSI is a COM library that is already installed. It can be used from VBScript but otherwise > has nothing to do with it. > Your link gives directions to download and register the file, so it's apparently not already installed on all systems. (Maybe you mean the XP SP2+ "supported systems" and just can't be bothered to mention that detail for clarification?) The links I find seem to all refer to script. And they refer to the file as being part of the ADSI SDK, not the system. I got a lot of hits on Google about people looking for a download link. And the MS pages I find -- your link and this: http://support.microsoft.com/kb/279682 -- both show VBS sample code. Obviously that *can* be used from VB, but it appears to be an ActiveX DLL designed for script. In addition, according to your link, it takes some work to get the permissions inherited. And this conversation implies that the file is really for AD use, not ideal for setting permissions: http://74.125.47.132/search?q=cache:OD6KsVs9gwAJ:www.experts-exchange.com/Se curity/Win_Security/Q_21019361.html+ADsSecurity.DLL+available+download&cd=13 &hl=en&ct=clnk&gl=us So what's the point? I posted a link to basic API code that sets inherited permissions. Why would one choose ADsSecurity.DLL over that? So that you can later come back and say it would have been easier in .Net?
From: Paul Clement on 8 Mar 2010 12:47 On Mon, 8 Mar 2010 10:24:48 -0500, "mayayana" <mayayana(a)nospam.invalid> wrote: � > � � > � Those are both VBScript hacks with dependencies. � > � > � > Nope. ADSI is a COM library that is already installed. It can be used from � VBScript but otherwise � > has nothing to do with it. � > � � Your link gives directions to download and � register the file, so it's apparently not already � installed on all systems. (Maybe you mean � the XP SP2+ "supported systems" and just can't � be bothered to mention that detail for � clarification?) � � The links I find seem to all refer to script. � And they refer to the file as being part of the � ADSI SDK, not the system. � � I got a lot of hits on Google about people � looking for a download link. And the MS pages � I find -- your link and this: � � http://support.microsoft.com/kb/279682 � � -- both show VBS sample code. Obviously that � *can* be used from VB, but it appears to be � an ActiveX DLL designed for script. In addition, � according to your link, it takes some work to � get the permissions inherited. � � And this conversation implies that the file is � really for AD use, not ideal for setting permissions: � � http://74.125.47.132/search?q=cache:OD6KsVs9gwAJ:www.experts-exchange.com/Se � curity/Win_Security/Q_21019361.html+ADsSecurity.DLL+available+download&cd=13 � &hl=en&ct=clnk&gl=us � � � So what's the point? I posted a link to basic � API code that sets inherited permissions. Why � would one choose ADsSecurity.DLL over that? � So that you can later come back and say it would � have been easier in .Net? � You dismissed both as VBScript hacks and that was not true. That was all that I was pointing out in my reply. I am certain that you understand that both of the COM libraries can be used from VB 6.0 (you only need the ADsSecurity.DLL). Kind of ironic that the solution chosen by the OP at the Experts Exchange link you posted implemented the scripting solution from my first link. ;-) In any event, I'm not really going to debate which is the *best* method, and I didn't dismiss yours. I'll leave it up to the OP to chose. My reason for posting those examples is that they are alternatives to the Windows security API, which can be fairly complicated, especially if it needs to be modified in order to satisfy the requirements. I didn't really see any reason to attack my suggestions and mislead. I did not attack yours. Paul ~~~~ Microsoft MVP (Visual Basic)
From: mayayana on 9 Mar 2010 10:05 > I didn't really see any reason to attack my suggestions and mislead. I did not attack yours. > They're not "mine" or "yours". They're just code. If you have any useful critique of limitations or issues with the code I linked then I'd be very interested to know about those. In my usage that code has been dependable, simple, and it's easy to add into a project. (There is one caveat: it's designed for setting or removing permissions for all. As written the class doesn't deal with setting fine-grained permissions for specific people. The logic in that is that it's usually not relevant -- as is true in this case.) You're supposed to be an expert in VB. I don't see how you can prefer shelling to a utility or calling a specialized COM DLL over simple, concise API code. Both of the methods you're suggesting provide VBS samples for a good reason: They're aimed at system admins who don't have access, knowledge, or tools to use the API. What could be more of a hack in compiled software than shelling out to a command line utility designed for system admins? > Kind of ironic that the solution chosen by the OP > at the Experts Exchange link you posted > implemented the scripting solution from my first link. ;-) Ironic? Yes, the OP decided to call xcacls via WScript.Shell. You think that makes your case? The link is a discussion between scripters using VBS under the WSH!
From: Paul Clement on 9 Mar 2010 10:56
On Tue, 9 Mar 2010 10:05:25 -0500, "mayayana" <mayayana(a)nospam.invalid> wrote: � � > I didn't really see any reason to attack my suggestions and mislead. I did � not attack yours. � > � � They're not "mine" or "yours". They're just code. � If you have any useful critique of limitations or � issues with the code I linked then I'd be very � interested to know about those. In my usage that � code has been dependable, simple, and it's easy � to add into a project. (There is one caveat: � it's designed for setting or removing permissions � for all. As written the class doesn't deal with � setting fine-grained permissions for specific � people. The logic in that is that it's usually not � relevant -- as is true in this case.) � � You're supposed to be an expert in VB. I don't � see how you can prefer shelling to a utility or � calling a specialized COM DLL over simple, concise � API code. Both of the methods you're suggesting � provide VBS samples for a good reason: They're aimed � at system admins who don't have access, knowledge, � or tools to use the API. What could be more of a hack � in compiled software than shelling out to a command � line utility designed for system admins? I didn't state a preference, simply a couple of alternatives. Like I said, it's up to the OP. If he is comfortable working with the Windows API and the solution satisfies his requirements then by all means I see no reason why he shouldn't use it instead of the alternatives. � > Kind of ironic that the solution chosen by the OP � > at the Experts Exchange link you posted � > implemented the scripting solution from my first link. ;-) � � Ironic? Yes, the OP decided to call xcacls via � WScript.Shell. You think that makes your case? � The link is a discussion between scripters using � VBS under the WSH! � It's not about making a case. What I choose to implement may be different than what you or someone else may choose, based upon knowledge, experience, requirements and other factors. Paul ~~~~ Microsoft MVP (Visual Basic) |