difference in windows explorer and window search with file path

[questorfla]

This is an unusual situation that just occurred and the techs from the company who wrote the software have no idea and neither do I.  But it is creating a huge problem.

This is a database program that has to be loaded with file links and the only path it will allow is the mapped network drive letter path. for example  R:\docs\filename can be linked to the record in the database as the location for a specific file

This is done by browsing to the R:\docs folder and scrolling down to find the correct file which when clicked fills in the path as R:\docs\"filename" in the database record. 
However:
if the same process is followed and the User decides they want to search for the file in the docs folder, and once the file is found they click it.  THIS time Window Search fills in the database record for the file location using the full UNC path to the file...Without using the Mapped drive letter of R:
The database program has a setting that will not allow it to accept ANY paths that are not specific the the mapped drive letter.   So those that try to input with the UNC path (which is 100% correct in every way) are not accepted with an error that they are not allowed to use other paths that the one with the mapped drive letter.
I can't find any problems with the system  Everything checks out 100% and as long as the user stays in Windows explorer and scrolls down to find the file it always uses the mapped drive letter. 
Does anyone have any idea as to why using SEARCh in that mapped drive location would return a long \\remote server\mapped folder name\filename" and fill it in instead.  It will not work linked like that but if they go back and scroll to the file from the folder it is in, it works properly every time.
And yes, the UNC path translates to the exact mapped network drive path
This ONLY happens if they try to search for the file and it must be something new as no one has ever had this come up before.
My only hope at this time i tuse the old Vsubst program which always seemed to work right.  But no one has ever reported a problem using search before now.  Although i dont really see the need to use search when there are not that many files to scroll though.  Still, i also dont see any reason for Window to return the full UNC path when using deach and yet retunth normal R:\Docs\filename when scrolling tot it.
I have considered the possibility of rebuilding he windows index on that system. I dont yet know if this same bug affects all systems

Thanks

[Ath]

It is the result of how windows account separation works.
Search is done by a background/service process, and that process is running under another (system) account, not your current-user account. Drive mappings are specific to user accounts, so the service process can't know how your mappings are configured. To start the search, Explorer hands down the unc path of the folder to the search process, so search doesn't have a clue you are even using a mapped drive. Translating that back to a user-local mapped drive is a job for the application receiving the path to the file, as Explorer doesn't do that for you. (Retrieve all mapped drives and substitute the mapping-unc path part with the mapped drive in the found filepath).

[questorfla]

Thanks for your reply ATH.  I wish that was all it was.  But i have it on good authority that MS  intends to do away with supporting mapped drives eventually.  It is just a matter of how soon they fully implement it.  Fully Qualified or  'UNC' paths will be the required way to link to a fie on a shared network location.  From what i understand it has something to do with ensuring security and constant compliance with other network functions.

Sorry i did not get the email telling me you had replied here as well.  I have been so tied up trying to fix this problem with all the links being wrong in a major company database because the Users tried to force a solution on a problem that made things worse instead of better,

I should add that your explanation is probably True as well  !  Thanks for the detailed explanation.


What no one can figure out is why this has never happened in the past.  The Users have always used the search function in explorer and it always returned the mapped drive letter (or so i have been told.. I do not personally do data entry so it could be that no one ever tried using search and they just dont remember it that way.

[wraith808]

MS  intends to do away with supporting mapped drives eventually.

-questorfla (August 15, 2018, 04:52 PM)

I'd like to know the source for that one.  I can't imagine them doing that.  Some things just don't work over UNCs.

[questorfla]

I'm with you Wraith and I also questioned their veracity on this topic. 

I posted a reply asking to be provided with the source for this information in writing as I also find this extremely hard to believe.  I can give you verbatim what they said but it would be impolite to pass along User names from another forum.   See next in quotes:

"It is my understanding that Microsoft is slowly doing away with mapped drive support and is wanting everyone to begin using UNC instead. At this point mapped drives are basically still around as a nod to programs such as yours that still require drive letters instead of UNC paths. "

On the topic of the problem itself, i was finally able to track down the reason for it by going off site and reconnecting through a VPN.  Connected Like that, i was given a lot more choices for where to start the search so I could see what was causing the whole problem.  It is caused by the way the database software is directing the request for the path.  Unless the User redirects Search to Begin at the the start of the mapped drive letter, it is by default using the already interpreted UNC path as the start.

SO:  Hat's off to you ATH,    Essentially you are 100% correct!  The software has the user already inside the UNC path before it even starts the search.  This was WHY it always returned the found items on their UNC path instead of the path using the mapped drive letter.  Fixing it just requires the User to point Search at the mapped letter before it begins.

So that is the end of MY problem. 
But like you, I would like to know where this one person got their info from re: Windows dropping support for mapped drive letters.  I promise to pass this along if i can get it.

[KodeZwerg]

You can also integrate a function that convert UNC to absolute path.

In Delphi its done like this:

Code: Delphi [Select]

1. Type
2.     tShareInfo = Record
3.         NetName: pWideChar;
4.         ShareType: LongWord;
5.         Remark: pWideChar;
6.         Permissions: LongWord;
7.         MaxUses: LongWord;
8.         CurrentUses: LongWord;
9.         Path: pWideChar;
10.         Passwd: pWideChar;
11.     End;
12.     pShareInfo = ^tShareInfo;
13.  
14. Function NetShareInfo(ServerName, NetName: String): tShareInfo;
15. Var
16.     TempPointer: Pointer;
17.     TempInfo: pShareInfo;
18. Begin
19.     GetMem(TempPointer, 10);
20.     If NetShareGetInfo(pWideChar(WideString(ServerName)), pWidechar(WideString(NetName)), 2, TempPointer) = 0 Then
21.     Begin
22.         TempInfo := pShareInfo(TempPointer^);
23.         Result := TempInfo^;
24.     End
25.     Else
26.         FillChar(Result, SizeOf(Result), #0);
27.     FreeMem(TempPointer, 10);
28. End;
29.  
30. Var
31.     MyInfo: tShareInfo;
32.  
33. Begin
34.     WriteLn('Getting share information.');
35.     MyInfo := NetShareInfo('SERVER', 'EXAMPLESHARE');
36.     WriteLn('The local path is: ', MyInfo.Path);
37.     WriteLn('Press [enter] to finish.');
38.     ReadLn;
39. End.