 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / General / March 2010Create Folders and Write To Hard Disk Other than C:
My app can generate many gigabytes of data files (several megabytes each) per the user choice. For those who wonder, this happens over many hours and or days. I am making XP and up a requirement for using the app. So, for XP and up how do I do the following: (1)Set permissions on a different hard drive (other than C:) to read, write and delete data files. (a)for this user (b)for all users (common data). (2)Create a folder (assumes this is different than "normal"). I may be totally wrong, but I assume that reading, writing and deleting the file in this folder once created is as usual. (3) when I reopen the app, do I need to do anything if I find the folder previously created? e.g. set permissions again? etc. There's a compact class here that I use for my installers: http://www.jsware.net/jsware/vbcode.php5#perms There are 3 function: 1) Check the partition formatting. (XP is not necessarily on NTFS. It may be on FAT32. And a data partition can be FAT32. Permissions only apply to NTFS.) 2) Get current permissions on a file/folder/Registry key. 3) Set permissions on a file/folder/Registry key. The setting permissions function is basic: add or remove full permission for all. > My app can generate many gigabytes of data files (several megabytes each) per > the user choice. For those who wonder, this happens over many hours and or [quoted text clipped - 15 lines] > (3) when I reopen the app, do I need to do anything if I find the folder > previously created? e.g. set permissions again? etc. thanks but is it correct that the user can only set the permission level to him/herself and not allow the data to be shared by others? I need to allow the text and image files that the user creates to be shared by all users. the user controls the generation and amount of data. and as i have stated, it may be mandatory for the user to select a different drive than C: due to space limitations. > There's a compact class here that I use for my installers: > [quoted text clipped - 37 lines] > > . > thanks > but is it correct that the user can only set the permission level to [quoted text clipped - 3 lines] > and as i have stated, it may be mandatory for the user to select a different > drive than C: due to space limitations. I think that Nobody addressed that. You need to create the folder(s) during install when you're running as Admin. Failing that, you'd need another process that runs as Admin, or just leave it up to the person using the software to log on as Admin when they create the folder. Nobody's explanation is pretty much what I thought was the case: Someone who's running as a normal user can create a folder, but other "normal users" can't access it. > My app can generate many gigabytes of data files (several megabytes each) > per [quoted text clipped - 19 lines] > (3) when I reopen the app, do I need to do anything if I find the folder > previously created? e.g. set permissions again? etc. My recommendation is to change your approach. There is NO reason whatsoever that your app should have to mess around with setting permissions. This is just going to lead to trouble down the road. If it's a "user's choice" then let the user specify where these data files should be created. And to that end, the user should only be specifying a location which he/she already has permissions.  SignatureMike spankings do not work with me and it did little to help with the question. so how is the home user supposed to know how to set permissions? most of them can barely start an application. people have a right to use their PC as they choose so I am providing a option for them. read OPTION ! so they do not have to deal with the UAC at every mouse click. P.S. logical suggestions work with me. > > My app can generate many gigabytes of data files (several megabytes each) > > per [quoted text clipped - 26 lines] > end, the user should only be specifying a location which he/she already has > permissions. > spankings do not work with me and it did little to help with the question. > [quoted text clipped - 5 lines] > > P.S. logical suggestions work with me. Quite an attitude for somebody constantly asking for help. Fine, I won't offer suggestions to you anymore. Happy? SignatureMike Where is the suggestion on WHAT TO DO? > > spankings do not work with me and it did little to help with the question. > > [quoted text clipped - 9 lines] > > Fine, I won't offer suggestions to you anymore. Happy? > My recommendation is to change your approach. There is NO reason whatsoever > that your app should have to mess around with setting permissions. Maybe I read it wrong, but it sounds to me like he's thinking of providing storage on a non-C drive because the saved files are so bulky. And that storage will sometimes be per-user and sometimes be accessible to all. If D:\MusicStore\ needs to be accessible to all, on an NTFS system, I suspect that *does* need permissions set. Your adamant position of "NO reason whatsoever" needs a qualifier: "....if this is software designed for use by corporate employees on company workstations." My impression is that his software is mainly for home use. Or do you really believe that in no case, on no PC, should people ever be allowed to share files from a common folder? > to all. If D:\MusicStore\ needs to be accessible to all, > on an NTFS system, I suspect that *does* need > permissions set. By default, members of the "Users" group and unelevated admins can create folders and files under the root of an NTFS drive, they can read and write to them, but other users don't have write access to these files and folders. Elevated Administrators and Power Users can read or write to these locations. This is the same situation as with CSIDL_COMMON_APPDATA. > By default, members of the "Users" group and unelevated > admins can create folders and files under the root of an [quoted text clipped - 3 lines] > write to these locations. This is the same situation as with > CSIDL_COMMON_APPDATA. You see, there's the main problem in a nutshell. Regarding what you have just said, as far as the ordinary home user is concerned you might as well be talking Japanese! The main problem is that Micro$oft is run by a bunch of corporate lunatics and they are using their monopoly to sell corporate workstations to home users, which is not what most people really want. Anything a programmer can do to give control back to the purchaser of the computer and its operating system is a good thing in my view, and I agree with Bee on this point. Mike > My app can generate many gigabytes of data files (several megabytes each) > per [quoted text clipped - 19 lines] > (3) when I reopen the app, do I need to do anything if I find the folder > previously created? e.g. set permissions again? etc. Setting the permissions will not work unless the user has enough privileges, so if user can't do it with Windows Explorer, your application can't, it would get access denied errors. One solution is at install time, install an ActiceX EXE and configure it to run as SYSTEM, then talk to it using your app. This AX EXE would change the permissions for you. Another approach is to use the already available writable folders. Here are some choices: 1 - Per user: Use CSIDL_LOCAL_APPDATA. You cannot use CSIDL_APPDATA or CSIDL_PERSONAL(My Documents) because if roaming was enabled, it would take forever for the user to log on or log off. When a roaming user logs on or off, his profile(including My Documents, and CSIDL_APPDATA, and the user's version of HKEY_CURRENT_USER) are transported back and forth from a server, so this would take a long time if there are big files in these locations. 2 - All users: Use CSIDL_COMMON_DOCUMENTS. This is usually in XP/2003: C:\Documents and Settings\All Users\Documents In Windows Explorer, go to the bottom of the folders list and try to find "Shared Documents". This is the friendly name of the above folder. In Vista+, this is "C:\Users\Public\Documents", with a friendly name "Public Documents" under a friendly name "Public" folder. This folder, unlike CSIDL_COMMON_APPDATA, can be read and written to by all users without needing to change the permissions. It's for user saved files that are meant to be shared by all users on the same computer. It's not "suitable" for INI files and the like as much as they are not suitable in "My Documents" folder. They would be seen as being stored in an odd place. Problem is - what if there is no room on the C: drive and there is a 2T drive on E: ? What then? How does anyone handle this? I am not going to tell users to move files off the C: drive. And the C: drive may be to small for what they want to do, so they bought a 2T Drive for data. Shared Data! I cannot limit what the user wants to do except for the physical size of a disk on their system, no necessarily C: More Suggestions? Please! > > My app can generate many gigabytes of data files (several megabytes each) > > per [quoted text clipped - 53 lines] > > . >> (3) when I reopen the app, do I need to do anything if I find the folder >> previously created? e.g. set permissions again? etc. [quoted text clipped - 4 lines] > ActiceX EXE and configure it to run as SYSTEM, then talk to it using your > app. This AX EXE would change the permissions for you. Or just configure it to ask for elevation: http://hashvb.earlsoft.co.uk/Vista_UAC_and_Elevation#COM_elevation SignatureDee Earley (dee.earley@icode.co.uk) i-Catcher Development Team iCode Systems ¤ My app can generate many gigabytes of data files (several megabytes each) per ¤ the user choice. For those who wonder, this happens over many hours and or ¤ days. ¤ ¤ I am making XP and up a requirement for using the app. ¤ So, for XP and up how do I do the following: ¤ ¤ (1)Set permissions on a different hard drive (other than C:) to read, write ¤ and delete data files. ¤ (a)for this user ¤ (b)for all users (common data). ¤ ¤ (2)Create a folder (assumes this is different than "normal"). ¤ ¤ I may be totally wrong, but I assume that reading, writing and deleting the ¤ file in this folder once created is as usual. ¤ ¤ (3) when I reopen the app, do I need to do anything if I find the folder ¤ previously created? e.g. set permissions again? etc. The following should help you set permissions: http://support.microsoft.com/kb/825751 ADSI (which is a little more complicated): http://support.microsoft.com/kb/266461 I don't really understand what you're asking in questions 2 & 3. Paul ~~~~ Microsoft MVP (Visual Basic) I will take a look. Thanks > ¤ My app can generate many gigabytes of data files (several megabytes each) per > ¤ the user choice. For those who wonder, this happens over many hours and or [quoted text clipped - 30 lines] > Microsoft MVP (Visual Basic) > . > I will take a look. > Thanks Those are both VBScript hacks with dependencies. You don't need that. The link I gave you is simple, concise API code. ¤ > ¤ ¤ 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) > ¤ > ¤ 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? ¤ > ¤ ¤ > ¤ 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) > 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! ¤ ¤ > 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) > ¤ You're supposed to be an expert in VB. I don't > ¤ see how you can prefer shelling to a utility or [quoted text clipped - 7 lines] > > I didn't state a preference, simply a couple of alternatives. There's that intellectual dishonesty again. Patient: "Doctor, I have a really bad headache!" Doctor: "Well, you could take a couple of aspirin, hit your head against a wall until you knock yourself out, or just take these prescription painkillers along with a pint of whiskey. The choice is up to you! They're just a few possible alternatives!" > ¤ > Kind of ironic that the solution chosen by the OP > ¤ > at the Experts Exchange link you posted [quoted text clipped - 8 lines] > than what you or someone else may choose, based upon knowledge, experience, > requirements and other factors. Coward. Signature.NET: It's About Trust! http://vfred.mvps.org ¤ Paul Clement wrote: ¤ > ¤ 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. ¤ ¤ There's that intellectual dishonesty again. ¤ ¤ Patient: "Doctor, I have a really bad headache!" ¤ Doctor: "Well, you could take a couple of aspirin, hit your head ¤ against a wall until you knock yourself out, or just take these ¤ prescription painkillers along with a pint of whiskey. The choice is ¤ up to you! They're just a few possible alternatives!" Or you can just take a couple of aspirin or Tylenol or Advil, whichever works for you. Lets be intellectually honest and suggest something reasonable. OK? ¤ ¤ > ¤ > 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. ¤ ¤ Coward. Yeah I know, only your way is *the* right way. Paul ~~~~ Microsoft MVP (Visual Basic) > > I didn't state a preference, simply a couple of alternatives. > > There's that intellectual dishonesty again. On the other hand, there's something to be said for different approaches. Bee could switch to .Net and get the benefit of that 300MB wrapper. Then he could use the famous Interop to wrap wshom.ocx (wscript.shell), which wraps the call to ShellExecute, to call xcacls, which wraps the call to the permissions APIs. That way he'd have a "modern, up-to-date and supported solution". :) >>> I didn't state a preference, simply a couple of alternatives. >> [quoted text clipped - 8 lines] > APIs. That way he'd have a "modern, up-to-date and > supported solution". :) I think the barbituates and whiskey combo sounds preferable! Signature.NET: It's About Trust! http://vfred.mvps.org ¤ > > I didn't state a preference, simply a couple of alternatives. ¤ > ¤ > There's that intellectual dishonesty again. ¤ > ¤ ¤ On the other hand, there's something to be said ¤ for different approaches. Bee could switch to .Net ¤ and get the benefit of that 300MB wrapper. Then he ¤ could use the famous Interop to wrap wshom.ocx ¤ (wscript.shell), which wraps the call to ShellExecute, ¤ to call xcacls, which wraps the call to the permissions ¤ APIs. That way he'd have a "modern, up-to-date and ¤ supported solution". :) ¤ ShellExecute? Isn't that somewhat dated? ;-) He could just use Process.Start with the WaitForExit method if he wanted to run the scripts. The one MS KB article I found for .NET (C#) uses ADSI. It's really a shame that Microsoft wrote COM and .NET code wrappers for this API stuff isn't it. Otherwise, we would all be coding in C++. ;-) Paul ~~~~ Microsoft MVP (Visual Basic) > He could just use Process.Start with the WaitForExit method if he wanted to run the scripts. The one > MS KB article I found for .NET (C#) uses ADSI. How ...interesting. With .Net salesmen like you, who needs detractors? > It's really a shame that Microsoft wrote COM and .NET code wrappers for this API stuff isn't it. > Otherwise, we would all be coding in C++. ;-) I'm not doing either. Odd, huh? ¤ > He could just use Process.Start with the WaitForExit method if he wanted ¤ to run the scripts. The one ¤ > MS KB article I found for .NET (C#) uses ADSI. ¤ > ¤ ¤ How ...interesting. With .Net salesmen like you, ¤ who needs detractors? You brought it up. ¤ > It's really a shame that Microsoft wrote COM and .NET code wrappers for ¤ this API stuff isn't it. ¤ > Otherwise, we would all be coding in C++. ;-) ¤ > ¤ ¤ I'm not doing either. Odd, huh? ¤ Is that supposed to be intellectual honesty? ;-) If you are using VB 6.0 then you are certainly using COM wrappers. Paul ~~~~ Microsoft MVP (Visual Basic) > ¤ > It's really a shame that Microsoft wrote COM and .NET code wrappers for > ¤ this API stuff isn't it. [quoted text clipped - 3 lines] > ¤ > Is that supposed to be intellectual honesty? ;-) > If you are using VB 6.0 then you are certainly using COM wrappers. Ah, the famous Paul C. context switcheroo. Let me see if I've got this straight. You've just defended the choice of running VBScripts (that are shelling to sysadmin applets) via your 300 MB slop of superfluous wrappers, as preferable to using the API for setting permissions. ...And you equate your 300 MB script hack with using the VB intrinsic controls...because both involve wrappers. I understand now. You're a binary thinker! Am I actually having this conversation with a computer program? .... Oh... my.... I'm so embarassed! ¤ > ¤ > ¤ > It's really a shame that Microsoft wrote COM and .NET code wrappers ¤ for ¤ > ¤ this API stuff isn't it. ¤ > ¤ > Otherwise, we would all be coding in C++. ;-) ¤ > ¤ ¤ > ¤ I'm not doing either. Odd, huh? ¤ > ¤ ¤ > Is that supposed to be intellectual honesty? ;-) ¤ ¤ > If you are using VB 6.0 then you are certainly using COM wrappers. ¤ > ¤ ¤ Ah, the famous Paul C. context switcheroo. ¤ ¤ Let me see if I've got this straight. You've ¤ just defended the choice of running VBScripts ¤ (that are shelling to sysadmin applets) via your ¤ 300 MB slop of superfluous wrappers, as ¤ preferable to using the API for setting permissions. No actually I was replying with sarcasm to your sarcasm with respect to .NET. My actual suggestions, both VBScript and COM ADSI, have nothing to do with .NET. ¤ ...And you equate your 300 MB script hack with ¤ using the VB intrinsic controls...because both ¤ involve wrappers. Actually, the 300 MB script hack (whatever that means) was your idea. ;-) You seemed to have an issue with implementing VBScript, COM or .NET solutions and I was simply pointing out that all of these options are viable. Your preference for using the Windows API is fine, but the tone of your replies to the other suggestions seems to be somewhat snobbish. ¤ I understand now. You're a binary thinker! Am ¤ I actually having this conversation with a computer ¤ program? .... Oh... my.... I'm so embarassed! ¤ Maybe *you* should try binary thinking...or maybe not. ;-) Paul ~~~~ Microsoft MVP (Visual Basic) >> ¤ > It's really a shame that Microsoft wrote COM and .NET code wrappers > for [quoted text clipped - 22 lines] > I actually having this conversation with a computer > program? .... Oh... my.... I'm so embarassed! Not sure why he would be advocating that - since it's trivial to set acls from within the framework (System.Security.AccessControl). I do it all the time from my custom deployment tool. SignatureTom Shelton >>> ¤ > It's really a shame that Microsoft wrote COM and .NET code wrappers for >>> ¤ this API stuff isn't it. [quoted text clipped - 24 lines] > from within the framework (System.Security.AccessControl). I do it all the > time from my custom deployment tool. Because he was "answering" someone who wanted to do it with VB6!!! Y'know, the *charter* for this newsgroup. Jeeeeeez..... Signature.NET: It's About Trust! http://vfred.mvps.org >>>> ¤ > It's really a shame that Microsoft wrote COM and .NET code wrappers for >>>> ¤ this API stuff isn't it. [quoted text clipped - 26 lines] > > Because he was "answering" someone who wanted to do it with VB6!!! So, why is dotnet even in the conversation? > Y'know, the *charter* for this newsgroup. Jeeeeeez..... Yeah? SignatureTom Shelton >>>>> ¤ > It's really a shame that Microsoft wrote COM and .NET code wrappers >>>>> for ¤ this API stuff isn't it. [quoted text clipped - 28 lines] > > So, why is dotnet even in the conversation? Rhetorical question? (If not, what should be the obvious answer is, because Paul's here!) >> Y'know, the *charter* for this newsgroup. Jeeeeeez..... > > Yeah? Yeah. Signature.NET: It's About Trust! http://vfred.mvps.org >>>>>> ¤ > It's really a shame that Microsoft wrote COM and .NET code wrappers >>>>>> for ¤ this API stuff isn't it. [quoted text clipped - 31 lines] > Rhetorical question? (If not, what should be the obvious answer is, > because Paul's here!) Hmmm... maybe I need to read up the thread. I just was trying to figure out why someone was suggesting a call to a shell script to do something that can be done natively.... SignatureTom Shelton >>>>>>> ¤ > It's really a shame that Microsoft wrote COM and .NET code wrappers >>>>>>> for ¤ this API stuff isn't it. [quoted text clipped - 35 lines] > why someone was suggesting a call to a shell script to do something that can > be done natively.... Yeah, you're not the only one. In fact, on that count, you are basically channelling mayayana word for word. Signature.NET: It's About Trust! http://vfred.mvps.org ¤ >> So, why is dotnet even in the conversation? Because mayayana brought it up. ¤ > ¤ > Rhetorical question? (If not, what should be the obvious answer is, ¤ > because Paul's here!) ¤ > ¤ ¤ Hmmm... maybe I need to read up the thread. I just was trying to figure out ¤ why someone was suggesting a call to a shell script to do something that can ¤ be done natively.... I offered two suggestions, both of which where relatively easy to code (which is why I mentioned them). One used the script method and the other used ADSI. Mayayana suggested the Windows API. Easy enough to let the OP decide which method to use, but no, someone had to get their undies in a bundle over my suggestions Unlike .NET (sorry) there are no native functions or components in VB 6.0 that enable you to do this. Paul ~~~~ Microsoft MVP (Visual Basic) ¤ >> Because he was "answering" someone who wanted to do it with VB6!!! ¤ > ¤ > So, why is dotnet even in the conversation? ¤ ¤ Rhetorical question? (If not, what should be the obvious answer is, ¤ because Paul's here!) Yes, it's amazing how much mind control I can exercise with just my newsgroup presence. I can induce anyone to start spewing about .NET without even mentioning it myself. I guess they just can't help themselves. ;-) Paul ~~~~ Microsoft MVP (Visual Basic) > I can induce anyone to start spewing I think you misspelled "retching" but it's essentially the same either way, so, no biggie... Signature.NET: It's About Trust! http://vfred.mvps.org 2 & 3 are asking about permanence of the setting. by what i see so far, it is permanent until it is programmatically changed. not knowing the terminology yet, does the method talked about here in 825751 and 266461 need the logged in user to be a super admin to set permissions for all for a data folder. I am only storing text and images i create as directed by the user direct commands. if a business system admin want to stop this, then the app will be of no value to the user when used in this manner. i have seen that in business situatons a remote folder is assigned to a user and no other login other than the usual start up login is needed. so for he business case, this is actually simpler than for a home user. > ¤ My app can generate many gigabytes of data files (several megabytes each) per > ¤ the user choice. For those who wonder, this happens over many hours and or [quoted text clipped - 30 lines] > Microsoft MVP (Visual Basic) > . |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2010 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.