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: Alex Blekhman on 16 Mar 2007 11:19 "Larry Smith" wrote: >> 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. It was like this for WinNT/2K. Starting from WinXP/2K3 each user has its own set of drives: KB180362 - "INFO: Services and Redirected Drives" http://support.microsoft.com/kb/180362/ <quote> On Windows NT and on Windows 2000, drive letters are global to the system. All users on the system share the letters A-Z. Each user does not get their own set of drive letters. This means a user can access the redirected drives of another user if they have the appropriate security access. </quote> This is the exact situation that you describe. Following is description for XP/2K3: <quote> On Windows XP and on Microsoft Windows Server 2003, each logon session receives its own set of drive letters, A through Z. Therefore, redirected drives cannot be shared between processes that are running under different user accounts. </quote> Alex
From: Tom Serface on 16 Mar 2007 11:28 I most of the time find mapped drives to be a bad way to go and I use UNC's in my program whenever possible. The whole process breaks down quickly on a client/server architecture where the server machine may have a different set of mapped drives from the client. UNC's are a bit slower (don't know why), but a whole lot more reliable and easier to resolve. Tom "Alex Blekhman" <xfkt(a)oohay.moc> wrote in message news:%23SVxK69ZHHA.3984(a)TK2MSFTNGP02.phx.gbl... > "Larry Smith" wrote: >>> 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. > > It was like this for WinNT/2K. Starting from WinXP/2K3 each user has its > own set of drives: > > KB180362 - "INFO: Services and Redirected Drives" > http://support.microsoft.com/kb/180362/ > > <quote> > On Windows NT and on Windows 2000, drive letters are global to the system. > All users on the system share the letters A-Z. Each user does not get > their own set of drive letters. This means a user can access the > redirected drives of another user if they have the appropriate security > access. > </quote> > > This is the exact situation that you describe. Following is description > for XP/2K3: > > <quote> > On Windows XP and on Microsoft Windows Server 2003, each logon session > receives its own set of drive letters, A through Z. Therefore, redirected > drives cannot be shared between processes that are running under different > user accounts. > </quote> > > Alex
From: Larry Smith on 16 Mar 2007 11:38 >> 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. > > It was like this for WinNT/2K. Starting from WinXP/2K3 each user has its > own set of drives: > > KB180362 - "INFO: Services and Redirected Drives" > http://support.microsoft.com/kb/180362/ > <quote> > On Windows NT and on Windows 2000, drive letters are global to the system. > All users on the system share the letters A-Z. Each user does not get > their own set of drive letters. This means a user can access the > redirected drives of another user if they have the appropriate security > access. > </quote> > > This is the exact situation that you describe. Following is description > for XP/2K3: > > <quote> > On Windows XP and on Microsoft Windows Server 2003, each logon session > receives its own set of drive letters, A through Z. Therefore, redirected > drives cannot be shared between processes that are running under different > user accounts. > </quote> Thanks for pointing that out. It's been a while since I've dealt with these issues (obviously) but I'm surprised they would make a breaking change like this. I only quickly scanned this link but did notice the following exception: "... drive letters that are mapped from a service that is running under the local System account are visible to all logon sessions." In any case, these changes are an improvement IMO. Moreover, mapped drive letters are really intended for human eyes only. UNC names should be used in code when possible.
From: Alexander Grigoriev on 16 Mar 2007 14:53 Note that a service under non-human account cannot access other machine's drives anyway (except for some cases in domain environment). "Larry Smith" <no_spam@_nospam.com> wrote in message news:emlgxE%23ZHHA.4888(a)TK2MSFTNGP06.phx.gbl... > > In any case, these changes are an improvement IMO. Moreover, mapped drive > letters are really intended for human eyes only. UNC names should be used > in code when possible. >
From: Larry Smith on 16 Mar 2007 15:58
> Note that a service under non-human account cannot access other machine's > drives anyway (except for some cases in domain environment). That's only true for the System account in a non-domain environment (assuming that the guest account or NULL sessions don't come into play - I don't recall the situation for "Everyone" but that may allow access also). The SID for the System account is identical on all machines (S-1-5-18) so it can't be distinguished. When running in a domain however, the System account operates as "DomainName\MachineName" on the LAN and should be able to access a shared resource under that account. I'm basing this on dated information so if things have changed then I stand corrected.. |