CFileDialog Does not show mapped files in system account
in [Visual C]
|
Prev: CE 5.0 C++ solution will no longer load. The element 'VisualStudioUserFile' is used but not declared in the DTD/Schema
Next: Incorrect parameter
From: CrimeMaster on 16 Mar 2007 09:26 I have write some simple code,this code does not shows network mapped drives when we run it under system account, otherwise under user account it shows them correctly. Any body tell me why did its behaviour change under system account, and how we can do it under system account. CFileDialog fileDlg(TRUE); fileDlg.DoModal(); Regards, CrimeMaster
From: Larry Smith on 16 Mar 2007 10:25 >I have write some simple code,this code does not shows network mapped > drives when we run it under system account, otherwise under user > account it shows them correctly. > > Any body tell me why did its behaviour change under system account, > and how we can do it under system account. > > > CFileDialog fileDlg(TRUE); > fileDlg.DoModal(); Ok, I'm a little rusty at this since it's been a while. First, I've never actually tried running this dialog under the System account so I'm not sure what its behaviour will be. I'm not sure why you're doing this either since the System account isn't really intended for doing UI. work. However, if the drive mapping was created under a regular user account then it should still be available under the System account even though you don't see them. Trying accessing the drive in code for instance and it should succeeed in theory provided the System account has rights to the drive. If not then that might be the reason the dialog won't show it. In fact, I'd say it's a good bet that's what the problem is. That is, if you're running in a domain (probably) then the System account also has a domain account called "DomainName\MachineName". It's this account that requires rights to the network drive you're trying to access, not the original user account the mapping was created under. Note that since the "DomainName\MachineName" account is also a member of the "DomainName\Domain Computers" group then the System account will also have access if this group has access. I wouldn't depend on any of this however if you don't know what the target environment is going to be. It's best to bring the dialog up under an account you know has rights (usually the interactive user if there is one).
From: Alex Blekhman on 16 Mar 2007 10:26 "CrimeMaster" wrote: > I have write some simple code,this code does not shows > network mapped > drives when we run it under system account, otherwise > under user > account it shows them correctly. > > Any body tell me why did its behaviour change under system > account, > and how we can do it under system account. Drive mappings exist only under an accout, which created them. Read "Remarks" section in documentation for `WNetAddConnection2' function. Alex
From: Ben Voigt on 16 Mar 2007 10:30 Don't multipost, and don't create dialog boxes or any other kind of windows as SYSTEM. "CrimeMaster" <ajmal798(a)gmail.com> wrote in message news:1174051580.812249.176860(a)d57g2000hsg.googlegroups.com... >I have write some simple code,this code does not shows network mapped > drives when we run it under system account, otherwise under user > account it shows them correctly. > > Any body tell me why did its behaviour change under system account, > and how we can do it under system account. > > > CFileDialog fileDlg(TRUE); > fileDlg.DoModal(); > > > Regards, > CrimeMaster >
From: Larry Smith on 16 Mar 2007 11:04
> Drive mappings exist only under an accout, which created them. Read > "Remarks" section in documentation for `WNetAddConnection2' function. That's not true actually. While this entire area is flaky (it has its roots in the SMB=Server Message Block protocol), a drive mapping is a machine-wide alias for a UNC path. If you create it under one account then you should have access to it under another account. The other account still needs to be authenticated however against. So, for instance, if a service maps some drive letter and an interactive user then logs on, he/she will have access to the same drive. If this is drive G: for instance then the interactive user can access drive G but still needs to be authenitcated first (because the interactive user hasn't established an SMB session on the machine where drive G is located). The system will therefore implicitly map drive G for the interactive once authentication succeeds. Authentication is the real issue here and the source of most problems. That is, the account that created the mapping is different than any other account that wants to access the same mapping. The latter account doesn't get access just because the original account has access. The problem that you pointed is also an issue since the functions which retrieve these drives are screwy when run under a different account. Using the above scenario for instance, the interactive user won't be able to see drive G if they run the "net use" command from the command prompt. His problem might be the same (assuming it's not an authentication issue). |